This is too abstract for me. There are definitions in draft-ietf-netmod-yang-model-classification-01.txt - it helps us if you can tell us which ones are not precise enough or which ones are missing or which ones you think do not serve a useful purpose.
All I wanted to say is that boundaries will not be tight and I this is good as long as we have terms that should ease human communication. /js On Fri, Apr 08, 2016 at 06:45:01PM +0000, Alexander Clemm (alex) wrote: > 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/> -- 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
