> 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? > 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? > 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
