Subject: [netmod] YANG model classification?

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 6 Apr 2016 18:09:33 +0000

draft-ietf-netmod-yang-model-classification suggests that a YANG model is either a "Network Element YANG Model" or a "Network Service YANG Model".

How would draft-ietf-teas-yang-te-topo be classified according to that? Thoughts?

Thanks

Michael

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Wed, 6 Apr 2016 19:14:37 +0000

Is the YANG model in draft-ietf-teas-yang-te-topo expected to be implemented in a network element, on a management system or perhaps either?

--
Carl Moberg
Technology Director, CVG
[email-masked]

> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Apr 2016 16:31:00 -0300

My personal view is either. ..

On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" <[email-masked]> 
wrote:

>
>  Is the YANG model in draft-ietf-teas-yang-te-topo expected to be 
>  implemented in a network element, on a management system or perhaps either?
>
> --
> Carl Moberg
> Technology Director, CVG
> [email-masked]
>
>> draft-ietf-netmod-yang-model-classification suggests that a YANG model is 
>> either a "Network Element YANG Model" or a "Network Service YANG Model".
>>

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Wed, 6 Apr 2016 20:33:22 +0000

Not sure either captures the case where, in the same network, there are instances of the model on NEs and on the management systems.

Does  "both" cover that case ?

pd

There has already been discussion of the concept of a switch matrix (inside an NE) which can
On Apr 6, 2016, at 3:31 PM, Lou Berger <[email-masked]> wrote:

> On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" <[email-masked]> wrote:
> 
>>

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Wed, 6 Apr 2016 21:33:55 +0000

Exposing a model of a *network* seems like something more appropriate on a controller that sits above individual NEs and aggregates network wide information no ?  
Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of EXT Doolan, Paul (Coriant - US/Irving)
Sent: Wednesday, April 06, 2016 17:33
To: Lou Berger
Cc: [email-masked]
Subject: Re: [netmod] YANG model classification?

pd

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Wed, 6 Apr 2016 21:41:03 +0000

There is a case that can be made for topology models capable of exposing topologies both from the view of a participant node as well as an all-seeing orchestrator/controller.

--
Carl Moberg
Technology Director, CVG
[email-masked]

> On Apr 6, 2016, at 11:33 PM, Sterne, Jason (Nokia - CA) <[email-masked]> wrote:
>

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Thu, 7 Apr 2016 00:08:54 +0000

There's a fractal element to this. Depending on the scale at which you look at these things - be they networks, NEs or even the switching fabrics within those - they are all similar to the extent that you can describe their internal connectivity with a graph. 

I guess another way to look at this is that big networks are out of little networks built ;-)

pd

---

From: "Doolan, Paul (Coriant - US/Irving)" <[email-masked]>
Date: Thu, 7 Apr 2016 00:40:26 +0000

Hello Carl, 

Interesting comment. 

Would you agree with me that in principle a topology is a topology is a topology and, therefore,  that we should strive for a model that can be employed recursively at any level in such a (implied) hierarchy ?

When I  look at topology, i.e fundamentally at a graph, I wish to manipulate or exploit aspects of the properties represented by it. In principle it doesn't matter to me what it represents. I have the same primitives at my disposal to manipulate it regardless of what it represents . Obviously in practice I might want to check some identifier in/of the topology to ensure that it's not a national backbone I'm messing with when I intended to change an access link in my metro ;-)

Do you think that's a reasonable perspective from which to continue this discussion ?

pd

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Thu, 7 Apr 2016 08:08:17 +0000

--
Carl Moberg
Technology Director, CVG
[email-masked]

> On Apr 7, 2016, at 2:40 AM, Doolan, Paul (Coriant - US/Irving) <[email-masked]> wrote:
> 
> Hello Carl, 
> 
> Interesting comment. 
> 

 I don’t know :-) On a more serious note, I would suggest it is likely to depend on the intent of the model and all the common tradeoffs between trying to be general yet useful.

> Do you think that's a reasonable perspective from which to continue this discussion ?

 I come at this from the classification angle, so my interest is if the assumption that a YANG model can only be classified as a network service model XOR a network device model according to the definitions in draft-ietf-netmod-yang-model-classification (sections 2.1 and 2.2). Based on this discussion I take it that some models are intended to be able to serve in both roles. And we should make sure that it’s supported in our catalog structure.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 7 Apr 2016 08:55:19 +0000

> I come at this from the classification angle, so my interest is if the assumption that
> a YANG model can only be classified as a network service model XOR a network device model
> according to the definitions in draft-ietf-netmod-yang-model-classification (sections 2.1
> and 2.2). Based on this discussion I take it that some models are intended to be able to
> serve in both roles. And we should make sure that it’s supported in our catalog structure.

Regarding the XOR assumption for classification:

You may also want to think about YANG models that are NEITHER device NOR service models. For instance, what about RFC 6991? And I think other, more technical models presented this week may fall into a similar category ("generic"?).

Michael

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Thu, 7 Apr 2016 08:57:17 +0000

--
Carl Moberg
Technology Director, CVG
[email-masked]

> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 

 Very good point, thanks! That will need some additional thinking and writing.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Apr 2016 12:45:29 +0200

> You may also want to think about YANG models that are NEITHER device NOR service models. For instance, what about RFC 6991? And I think other, more technical models presented this week may fall int…

RFC 6991 is not really defining a data model, while ietf-yang-types
and ietf-inet-types are both YANG modules they do not define any data
nodes that can be implemented. Lets look at RFC 6020bis:

   o  data model: A data model describes how data is represented and
      accessed.

Anyway, the point is that RFC 6991 do not define any data nodes and
hence nothing that can be accessed. Perhaps it helps to import
terminology into the model classification document and to be explicit
that not all YANG modules define YANG data models.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 7 Apr 2016 08:56:40 -0300

> On Apr 7, 2016, at 7:45 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

This is a good definition to be added, as in the draft we are talking about classifying data models and we have to go through the document and make sure that we use data model instead of model consistently.

Dean

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2016 04:56:29 -0700

On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > according to the definitions in
> draft-ietf-netmod-yang-model-classification (sections 2.1
> > You may also want to think about YANG models that are NEITHER device NOR
> service models. For instance, what about RFC 6991? And I think other, more
> technical models presented this week may fall into a similar category
> ("generic"?).
> >
>

I brought this issue up for YANG 1.1 but there was no interest
or agreement that there is any problem or confusion.

http://www.netconfcentral.org/modulereport/iana-crypt-hash

Consider iana-crypt-hash that only contains  1 typedef and 3 features
that relate to implementation of that typedef.  According to YANG 1.1
and the YANG library, a server implement MUST NOT claim it
implements iana-crypt-hash.  Instead the server must say "I import
this module, but implement the features".  How can one implement
something that is supposedly only imported?  Very confusing.

There is only ONE data model in a YANG implementation,
which is composed of one or more modules.

/js
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Apr 2016 14:33:25 +0200 (CEST)

> something that is supposedly only imported?  Very confusing.

ietf-yang-library and 6020bis(*) uses the phrase "supported
features".  So, a server can advertise a module as imported, and list
the supported features.

(*) 6020bis actually uses the phrase "implement a feature" in one
sentence (last sentence in 7.20.1).  This should probably be changed
to "support a feature" in order to avoid confusion.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2016 05:39:47 -0700

On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > I come at this from the classification angle, so my interest is if
> the
> > > assumption that
> > > > > a YANG model can only be classified as a network service model XOR
> a
> > > network device model
How does one support a feature without implementing it?
This terminology is inconsistent and confusing.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Apr 2016 14:55:27 +0200 (CEST)

> This terminology is inconsistent and confusing.

The feature itself isn't very interesting.  If a server supports
feature A, it implements nodes that have if-feature "A" statements.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2016 07:06:15 -0700

On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia -
> DE)
> > > > > wrote:
> > > > > > > and 2.2). Based on this discussion I take it that some models
> are
> > > > > intended to be able to
> > > > > > > serve in both roles. And we should make sure that it’s
> supported in
> > > > > our catalog structure.
> > > > > >
> > > > > > You may also want to think about YANG models that are NEITHER
> device
> > > NOR
> > > > > service models. For instance, what about RFC 6991? And I think
> other,
> > > more
Except this is not at all how features are used in iana-crypt-hash.yang.
The features are clearly related to implementation of any leaf or leaf-list
that uses this typedef.  Perhaps this is an exception and we should have
never defined those features in the first place.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Apr 2016 16:21:48 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> that uses this typedef. 

Sure.  But the confusion comes from the term "implement" which in
ietf-yang-library means "implement data nodes".  When someone also say
"implement a feature", it might be confusing.  So I simply propose
that we stick to the phrase "support a feature", to avoid the
confusion.  Do you have some other idea?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Apr 2016 07:36:43 -0700

On Thu, Apr 7, 2016 at 7:21 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > > > > > I come at this from the classification angle, so my
> interest
> > > is if
> > > > > the
> > > > > > > assumption that
> > > > > > > > > a YANG model can only be classified as a network service
> model
> > > XOR
> > > > > a
> > > > > > > network device model
> > > > > > > and ietf-inet-types are both YANG modules they do not define
> any
> > > data
> > > > > > >    o  data model: A data model describes how data is
> represented
> > > and
> > > > > > >       accessed.
> > > > > > >
not really.  We already spent a lot of time on the 'conformance-type' leaf
and could not come up with consensus on something else.
Supported feature will have to be good enough.  It also applies to
if-feature
on an identity-stmt, which is only indirectly implemented.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 7 Apr 2016 16:43:51 +0000

I am wondering what purpose the classification really serves.  At the end of the day, it seems to me that we are trying to express a model hierarchy, and articulate what the layers in the hierarchy are.  A device model is thus at a lower layer than a service model.  An implementation of the service model may in turn have dependencies on the device model, but not the other way round.  

Where the models are instantiated - on a controller, on a "device", etc - seems to be secondary and incidental.  The boundaries are blurry, anyways.  A controller is a device too; some devices may contain virtualized controllers, and so on.  

One model that is relevant in this discussion seems to be the TMN model, as defined in ITU-T Recommendation M.3010.  This model defines a set of management layers - network element (device), network, service, business - with well defined funcional scope of each layer.  The layers / function hierarchy also imply an information  and data model hierarchy.  

Would it make sense to see if the layering in M.3010 could help guide YANG model classification, and reference those definitions?  

--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Carl Moberg (camoberg)
Sent: Thursday, April 07, 2016 1:57 AM
To: Scharf, Michael (Nokia - DE) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] YANG model classification?

--
Carl Moberg
Technology Director, CVG
[email-masked]

>> the assumption that a YANG model can only be classified as a network 
>> service model XOR a network device model according to the definitions 
>> in draft-ietf-netmod-yang-model-classification (sections 2.1 and 
>> 2.2). Based on this discussion I take it that some models are intended to be able to serve in both roles. And we should make sure that it’s supported in our catalog structure.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Apr 2016 09:07:37 +0200

Yes, the boundaries are blurry and it does not matter which layering
model you use. M.3010 does not change the fact that boundaries are
blurry.

I think it is not a problem. My understanding was that the I-D
primarily aims at establish a common vocabulary and it should IMHO
explicitely state that boundaries are blurry and that the main purpose
is to simplify 'human communication'. The classification is not for
'implementation'.

/js

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Fri, 8 Apr 2016 12:40:59 +0000

> On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) <[email-masked]> wrote:
> 

 The abstract tries to express the purpose:

“””
A consistent terminology would help with the categorization of
models, assist in the analysis the YANG data modeling efforts in the
IETF and other organizations, and bring clarity to the YANG-related
discussions between the different groups.
“”"

 And I’ve then tried to expand a little further in section 1.

 Happy to take feedback on it!

> Where the models are instantiated - on a controller, on a "device", etc - seems to be secondary and incidental.  The boundaries are blurry, anyways.  A controller is a device too; some devices may…

 The assumption here is that the location is indeed useful and suggests the classification of data models into two distinct abstraction layers. Topology is the area where I had a sense that the device and service classification may both apply to a single module.

> One model that is relevant in this discussion seems to be the TMN model, as defined in ITU-T Recommendation M.3010.  This model defines a set of management layers - network element (device), networ…

 The classification is fairly well aligned with the concepts in M.3010, covering the "Network management” and “Element management” layers. At least that’s the intent :-)

> Would it make sense to see if the layering in M.3010 could help guide YANG model classification, and reference those definitions?  

 Would be very happy to hear if you find we deviate (or lack) concepts or useful features from M.3010 that would make the classification more useful.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Apr 2016 06:10:01 -0700

Hi,

It is not that clear how the different types of modules or layers
impact the task of designing a YANG module.  It seems like
vendor vs. standard or device vs. service are somewhat arbitrary,
especially if virtualization is considered.

The terminology would be more relevant if the differences in
content of each type of module were clear.

Andy

On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) <[email-masked]>
wrote:

> > I am wondering what purpose the classification really serves.  At the
> end of the day, it seems to me that we are trying to express a model
> hierarchy, and articulate what the layers in the hierarchy are.  A device
> model is thus at a lower layer than a service model.  An implementation of
> the service model may in turn have dependencies on the device model, but
> not the other way round.
>
> > Where the models are instantiated - on a controller, on a "device", etc
> - seems to be secondary and incidental.  The boundaries are blurry,
> anyways.  A controller is a device too; some devices may contain
> virtualized controllers, and so on.
>
>  The assumption here is that the location is indeed useful and suggests
> the classification of data models into two distinct abstraction layers.
> Topology is the area where I had a sense that the device and service
> classification may both apply to a single module.
>
> > One model that is relevant in this discussion seems to be the TMN model,
> as defined in ITU-T Recommendation M.3010.  This model defines a set of
> management layers - network element (device), network, service, business -
> with well defined funcional scope of each layer.  The layers / function
> hierarchy also imply an information  and data model hierarchy.
>
>  The classification is fairly well aligned with the concepts in M.3010,
> covering the "Network management” and “Element management” layers. At least
> that’s the intent :-)
>
> > Would it make sense to see if the layering in M.3010 could help guide
> YANG model classification, and reference those definitions?
>
>  Would be very happy to hear if you find we deviate (or lack) concepts or
> useful features from M.3010 that would make the classification more useful.
>
> > --- Alex
> >
> >>> 2.2). Based on this discussion I take it that some models are intended
> to be able to serve in both roles. And we should make sure that it’s
> supported in our catalog structure.
> >>
> >> You may also want to think about YANG models that are NEITHER device
> NOR service models. For instance, what about RFC 6991? And I think other,
> more technical models presented this week may fall into a similar category
> ("generic"?).
> >

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Fri, 8 Apr 2016 13:18:31 +0000

> On Apr 8, 2016, at 3:10 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> 

 The intent of the classification is (imho) not intended to have much impact on how to design a module. Rather to provide a taxonomy to classify models when they are done (or being developed).

 I don’t see how virtualization would have an impact, any suggestions?

> content of each type of module were clear.

 The first paragraphs of the main sections (2.1, 2.2, 3.1-3.3) are meant(!) to explain this. Could you expand on what you think is missing?

> Andy
> 
> 
> On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) <[email-masked]> wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Apr 2016 06:36:45 -0700

On Fri, Apr 8, 2016 at 6:18 AM, Carl Moberg (camoberg) <[email-masked]>
wrote:

>  The intent of the classification is (imho) not intended to have much
> impact on how to design a module. Rather to provide a taxonomy to classify
> models when they are done (or being developed).
>

No suggestions other than the hierarchy of controller to device is not
always static.
Am I allowed to build a service layer on top of another service layer?
(e.g,  NMS --> EMS --> NE).  Am I allowed to treat an entire data center
as a device in a high level application?

>  The first paragraphs of the main sections (2.1, 2.2, 3.1-3.3) are
> meant(!) to explain this. Could you expand on what you think is missing?
>

No -- this is an Informational draft.
The content does not have to be actionable.  It only
has to be informative.

For decades SNMP completely ignored anything above the NE as out of scope.
We are making some progress just by considering the possibility of standard
functionality at the controller layer.

> > > Where the models are instantiated - on a controller, on a "device",
> etc - seems to be secondary and incidental.  The boundaries are blurry,
> > > One model that is relevant in this discussion seems to be the TMN
> model, as defined in ITU-T Recommendation M.3010.  This model defines a set
> of management layers - network element (device), network, service, business
> - with well defined funcional scope of each layer.  The layers / function
> >  Would be very happy to hear if you find we deviate (or lack) concepts
> or useful features from M.3010 that would make the classification more
> useful.
> >
> > > --- Alex
> > >
> > >>> 2.2). Based on this discussion I take it that some models are
> intended to be able to serve in both roles. And we should make sure that
> it’s supported in our catalog structure.
> > >>

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Fri, 8 Apr 2016 16:52:34 +0000

> On Apr 8, 2016, at 3:36 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Fri, Apr 8, 2016 at 6:18 AM, Carl Moberg (camoberg) <[email-masked]> wrote:
> 
> No suggestions other than the hierarchy of controller to device is not always static.

 The draft is definitely not supposed to tell you what you are allowed to do, but it does aspire to a useful classification of what people are doing :-)

 So, to your questions:

 1. “...a service layer on top of another service layer?"

 From section 2.1:

“”””
The component-based approach captures device-centric features (e.g.
the definition of a VRF, routing protocols, or packet filtering) in a
vendor-independent manner.  The components are designed for reuse
across many services.  The set of components required for a specific
service is then composed into the higher-level service.  The
component-based approach has the advantages of modular development
including a higher degree of reusability at the expense of initial
speed.
“””

 2. “...to treat an entire data center as a device in a high level application?"

“””
Network Element YANG Data Models describe the configuration, state
data and operations of a network device as defined by the vendor of
that device.  The models are commonly structured around features of
the device...
“”"

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 8 Apr 2016 18:22:56 +0000

Hi Carl,

to follow up on the earlier points in the discussion:
- How can we provide more clarification
- How could M.3010 provide something useful

FWIW, a line of argument to reflect in the draft might go as follows: 

Given that the history in IETF has been to not look at things beyond the device boundary, perhaps it would be useful to state somewhere that this restriction no longer holds and needs to be relaxed - given that devices can be virtualized, controllers may reside on devices, that applications may become more network-aware and networks more service / application aware, etc.  So, the boundaries are getting more blurry.  

At the same time, a foundational concept is still the need for function hierarchies (regardless of details of where and how those functions are instantiated): elementary functions / building blocks (formerly equivalent to devices), functions that deal with the connection of those functions / building blocks (formerly equivalent to "network management" in the narrower sense), then functions that build higher-level services on top of connectivity already being provided.  Function hierarchies imply information / data hierachies.  There is no reason why YANG could not be used to define models at different levels of that hierarchy, which provides various advantages such as consistency across the "model stack" as well as the ability to make aspects of models at different levels of abstraction accessible to other models and be used together where layering is not "strict" (in the sense that upper layers may build on top of models from multiple lower layers, not just the layer immediately below it, so that lower layers are not completely hidden).  So, YANG models apply to different layers, and there are advantages in doing so. 

The concept of model hierarchies is not new.  One example of a hierarchical classification that has proved very useful over the years is the hierarchy spelled out in M.3010.  So, we are not proposing anything "radical" here; there is precedence.  As M.3010 layering concepts are in essence applicable also here, yet the need for data model hierarchies has not been spelled out before in the context of the YANG/Netconf framework, this is an attempt to fill that gap.   

One reason why classification is useful in that sense is to know which types of models might have dependencies on each other, and what other models a model might build on when instantiated.  Upper-layer models may have dependencies on lower-layer models, and in many cases aggregate/abstract multiple components from those lower layer models, but not the other way around.  This means that, upper-layer models may be instantiated in different ways than lower-layer models in as far as they build on top of other functions/models of the same framework (instead of functions outside that framework).  This distinction is one of the reasons why having a clear classification is something that may be useful.  

Anyway, IMHO, what is currently not sufficiently clear from the draft is that classification does not occur just for classification's sake, and this is an attempt at articulating a case for it.  

Cheers
--- Alex 

-----Original Message-----
From: Carl Moberg (camoberg) 
Sent: Friday, April 08, 2016 9:53 AM
To: Andy Bierman <[email-masked]>
Cc: Alexander Clemm (alex) <[email-masked]>; [email-masked]
Subject: Re: [netmod] YANG model classification?

> > impact the task of designing a YANG module.  It seems like vendor 
> > vs. standard or device vs. service are somewhat arbitrary, 
> (e.g,  NMS --> EMS --> NE).  Am I allowed to treat an entire data 
> center as a device in a high level application?
> 

 So, to your questions:

 From section 2.1:

“”””
The component-based approach captures device-centric features (e.g.
the definition of a VRF, routing protocols, or packet filtering) in a vendor-independent manner.  The components are designed for reuse across many services.  The set of components required for a specific service is then composed into the higher-level service.  The component-based approach has the advantages of modular development including a higher degree of reusability at the expense of initial speed.
“””

“””
Network Element YANG Data Models describe the configuration, state data and operations of a network device as defined by the vendor of that device.  The models are commonly structured around features of the device...
“”"

> > The terminology would be more relevant if the differences in content 
> > of each type of module were clear.
> 
> The content does not have to be actionable.  It only has to be 
> informative.
> 
> We are making some progress just by considering the possibility of 
> standard functionality at the controller layer.
> 
> 
> > Andy
>  
> >
> >
> >  The classification is fairly well aligned with the concepts in 
> > M.3010, covering the "Network management” and “Element management” 
> > layers. At least that’s the intent :-)
> >
> > >>> I come at this from the classification angle, so my interest is 
> > >>> if the assumption that a YANG model can only be classified as a 
> > >>> network service model XOR a network device model according to 
> > >>> the definitions in draft-ietf-netmod-yang-model-classification 
> > >>> (sections 2.1 and 2.2). Based on this discussion I take it that some models are intended to be able to serve in both roles. And we should make sure that it’s supported in our catalog structure.
> > >>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 8 Apr 2016 18:45:01 +0000

Hi Juergen, the question is still _how_ it simplifies human communication.  To use different terms, it should be clear what different purposes they convey, and why their distinction is relevant and matters.  IMHO this needs to be articulated more clearly. If it is not clear why the distinction matters, it does not simplify communication.  
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, April 08, 2016 12:08 AM
To: Alexander Clemm (alex) <[email-masked]>
Cc: Carl Moberg (camoberg) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; [email-masked]
Subject: Re: [netmod] YANG model classification?

Yes, the boundaries are blurry and it does not matter which layering model you use. M.3010 does not change the fact that boundaries are blurry.

I think it is not a problem. My understanding was that the I-D primarily aims at establish a common vocabulary and it should IMHO explicitely state that boundaries are blurry and that the main purpose is to simplify 'human communication'. The classification is not for 'implementation'.

/js

On Thu, Apr 07, 2016 at 04:43:51PM +0000, Alexander Clemm (alex) wrote:
> >> the assumption that a YANG model can only be classified as a 
> >> network service model XOR a network device model according to the 
> >> definitions in draft-ietf-netmod-yang-model-classification

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 10 Apr 2016 17:31:09 +0200

This is too abstract for me. There are definitions in
draft-ietf-netmod-yang-model-classification-01.txt - it helps us if
you can tell us which ones are not precise enough or which ones are
missing or which ones you think do not serve a useful purpose.

All I wanted to say is that boundaries will not be tight and I this is
good as long as we have terms that should ease human communication.

/js

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 10 Apr 2016 15:49:57 +0000

Having tight boundaries may also be non-trivial without making further assumptions about the actual system that uses YANG (data) models.

Personally, I'd be fine with a wording that simply acknowledges that there are grey areas.

Michael

> From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Sunday, April 10, 2016 5:31 PM
> To: Alexander Clemm (alex)
> Cc: Carl Moberg (camoberg); Scharf, Michael (Nokia - DE);
> [email-masked]
> > Hi Juergen, the question is still _how_ it simplifies human
> communication.  To use different terms, it should be clear what
> different purposes they convey, and why their distinction is relevant
> and matters.  IMHO this needs to be articulated more clearly. If it is
> not clear why the distinction matters, it does not simplify
> communication.
> > --- Alex
> >
> > Cc: Carl Moberg (camoberg) <[email-masked]>; Scharf, Michael
> (Nokia - DE) <[email-masked]>; [email-masked]
> > > I am wondering what purpose the classification really serves.  At
> the end of the day, it seems to me that we are trying to express a
> model hierarchy, and articulate what the layers in the hierarchy are.
> A device model is thus at a lower layer than a service model.  An
> implementation of the service model may in turn have dependencies on
> the device model, but not the other way round.
> > >
> model, as defined in ITU-T Recommendation M.3010.  This model defines a
> set of management layers - network element (device), network, service,
> business - with well defined funcional scope of each layer.  The layers
> / function hierarchy also imply an information  and data model
> hierarchy.
> > >
> > > Would it make sense to see if the layering in M.3010 could help
> guide YANG model classification, and reference those definitions?
> > >
> > > --- Alex
> > >
> > > From: netmod [mailto:[email-masked]] On Behalf Of Carl
> Moberg
> > > (camoberg)
> if
> > > >> (sections 2.1 and 2.2). Based on this discussion I take it that
> some models are intended to be able to serve in both roles. And we
> should make sure that it’s supported in our catalog structure.
> > > >
> device NOR service models. For instance, what about RFC 6991? And I
> think other, more technical models presented this week may fall into a
> similar category ("generic"?).
> > >

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Mon, 11 Apr 2016 11:01:57 +0000

> On Apr 8, 2016, at 8:22 PM, Alexander Clemm (alex) <[email-masked]> wrote:
> 
> Hi Carl,
> 

 What I was going after was if you find we deviate (or lack) concepts or useful features from M.3010 that would make the classification more useful. Hoping you could review the draft with M.3010 goggles on and see if we’re missing something useful!

> Given that the history in IETF has been to not look at things beyond the device boundary, perhaps it would be useful to state somewhere that this restriction no longer holds and needs to be relaxed…

 This to me seems to be a generally useful reflection, but I believe it to be out of scope for this draft.

> At the same time, a foundational concept is still the need for function hierarchies (regardless of details of where and how those functions are instantiated): elementary functions / building blocks…

 I’ve tried to cover this topic (or at least one instance of it) in section 2. I’ll re-review with the above in mind.

> The concept of model hierarchies is not new.  One example of a hierarchical classification that has proved very useful over the years is the hierarchy spelled out in M.3010.  So, we are not proposi…

 Exactly!

> Anyway, IMHO, what is currently not sufficiently clear from the draft is that classification does not occur just for classification's sake, and this is an attempt at articulating a case for it.  

 I’m trying to strike a balance between providing arguments for why abstractions are useful (which is out of scope for the draft imho) and how to classify YANG modules. Almost to the contrary, the draft mentions that there are currently no specific requirements on, or well-defined best practices around the development of modules inside the boundaries of this classification. As the people and technologies around YANG matures, I believe we will see more granular patterns of use that we may want to capture in future drafts.

>>>> Moberg (camoberg)