> 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
