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