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 protected]] Sent: Friday, April 08, 2016 12:08 AM To: Alexander Clemm (alex) <[email protected]> Cc: Carl Moberg (camoberg) <[email protected]>; Scharf, Michael (Nokia - DE) <[email protected]>; [email protected] 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: > 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 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 -- 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
