Hi Tom, Long time! > > What I see from 7950 is that a "YANG module" is a compilable blob of > > YANG that may include other modules or specific constructs from another > > module. That is clear enough. > > > > What is less clear is what a "data model" is or is not. I think that > > if, for example, I wanted to model a router, I would construct a data > > model from one or mode YANG modules that encode various aspects of the > > router. You could, I suppose, present that construct as a module its own > > right. > > > > And that leads me to ask you when it is appropriate to use term "data > > model". > > > > 8199 doesn't offer me a lot of clarity. For example, section 1 says: > > For example, a > > Layer 2 Virtual Private Network (L2VPN) YANG module might be a > > Network Service YANG Module, ready to be used as a service model > > by a network operator. > > > > Later (in 2.1) it says that a module "describes an abstract model" > > And (in 2.2) that a module "provides a coherent data model > > representation" > > > > All this means (I think) that modules are documentation, but models > > are used. > > > > It's all a bit esoteric for me and I can't find a way forward :-( > > > > What I want to do is observe that: > > - Modules a constructed from YANG and may include other whole YANG > > modules or specific elements from other YANG modules > > - Modules describe may define pieces of modelling that are only useful > > when applied in a context. For example, a module might define a > > YANG construct for a timestamp or an interface, but those constructs > > would only be useful when included in another module that gave > > context to the timestamp or interface. > > - Modules may also describe data models for components or > > sub-components of a managed system (often by including YANG from > > other modules). > > - Not all modules provide data models that are independently useful, > > but some do. And one example is that when we want to model > > something like a service, we use a service model that is presented > > in a single YANG module. Thus, it is perfectly reasonable that 7223 is > > called "A YANG Data Model for Interface Management" and 8049 is a > > "YANG Data Model for L3VPN Service Delivery". > > > > So, my inclination is to include pointers to the 7950 definitions, and > > to carefully re-read the text in our draft, but not to make a wholesale > > change of terms. > > > > Any clues? > > Adrian, > > What jumps out at me, as being an infelicitous of language, is the > first sentence, > " The IETF has produced many data modules in the YANG modeling > language. " > and that is because of 'data module'. > > Modules are compilable, as you say, because they are written in a > language, a data definition language, such as SMI, ABNF or even YANG, so > what you have is a SMI module or a YANG module; they appear in an RFC > and define a schema for data, arguably they are not the data itself, so > I think that 'data > module' is an oxymoron and that first sentence should be > " The IETF has produced many modules in the YANG modeling > language. "
That is good. We can avoid all "data modules". Four instances. > When RFC7950 defines data model as 'A data model describes how data is > represented and accessed' I think that it misses the point somewhat, > that a data model is in contrast to an information model as described in > RFC3444. That RFC suggests that all SMI modules are data models and so > by implication so would all YANG modules be. > > A YANG module for routing or interfaces can or will be a data > model but will a YANG module that defines data types for routing be? > um, unsure. > > I myself would avoid all uses of 'data model' But we have all the weight of recorded history :-) I've also cleaned up "YANG model". That seems to be wrong: we either have "data models" or "YANG modules". But the big distinction still eludes me. Perhaps you are right that the way forward is just to dodge the issue and only talk about modules. Adrian _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
