Hi Benoit,
>> In RFC 8199, we made a distinction between model and YANG modules.
>> This is why we defined the terms "Network Service YANG modules" and
>> "Network Element YANG modules" and not models. You should follow this
>> convention. After all, from the abstract, this document focuses on YANG.
>> Ex: should "model" be replaced by "YANG module"?
>
> The definition imported from 7950 by 8199 looks like a reasonable distinction
> and we will attempt to apply it here. I hope I am not importing too much
> thought from SMI but isn't a "model" built from one or modules? A model is
> used to "model" some larger entity or function, while a module is used to
> describe a component of an entity or a granular function.
>
> Probably just some cleanup needed through this document. I'll have a go.
Well, now I'm struggling and I wonder if you can help.
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?
Thanks,
Adrian
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
