On Fri, Apr 8, 2016 at 6:18 AM, Carl Moberg (camoberg) <[email protected]> wrote:
> > > On Apr 8, 2016, at 3:10 PM, Andy Bierman <[email protected]> wrote: > > > > 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 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? > 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 terminology would be more relevant if the differences in > > 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? > 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. > > Andy > > > > > > > On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) < > [email protected]> wrote: > > > > > On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) <[email protected]> > 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. > > > > 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 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 > > > > > > -----Original Message----- > > > From: netmod [mailto:[email protected]] On Behalf Of Carl > Moberg (camoberg) > > > Sent: Thursday, April 07, 2016 1:57 AM > > > To: Scharf, Michael (Nokia - DE) <[email protected]> > > > Cc: [email protected] > > > Subject: Re: [netmod] YANG model classification? > > > > > > > > > > > > -- > > > Carl Moberg > > > Technology Director, CVG > > > [email protected] > > > > > >> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) < > [email protected]> 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 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"?). > > > > > > Very good point, thanks! That will need some additional thinking and > writing. > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
