Martin,
Apologies, I switched to a new client and, wow, yes, it's not readable.
I reported a bug and switched clients again... I *hope* this one is more
readable (and it was when I checked last).
I'll put aside questions of whether the questions I'm asking are
completely fair. Apologies. They're written from my perspective of
problems I'm actually experiencing.
Martin Bjorklund <mailto:m...@tail-f.com>
August 27, 2015 at 15:45
1) As a consumer of YANG models, how do I identify the set of models
that provide a set of functionality?
I think that neither your proposed solution or what we have today (7
published modules) solves this problem.
I respectfully disagree. By defining some form of structure for the
models, I can have a logical grouping that gives me some pointers as to
where to find the right things that I need. I want to configure OAM,
great, let's go look at
/device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols
- because that's where all OAM stuff happens to live. If I have to
rather look through / to find a subset of some ping functionality in one
module, and some in another, it's not clear to me how I even start to
find the right thing - because at the moment one type of ping lives in
one module, and another in a completely different one, even though
they're almost identical in terms of management plane interface.
I agree, an alternative is that one can have something that has a
registry that defines sets of functionality, and we then need to define
the 'blocks' of functionality that we need (hey! this looks a lot like
some definition of a set of modules!). If this is a better solution,
yes, please, propose it. The way that we proposed in
openconfig-model-structure tries to have a way that you can not have a
single model code-block and pull in different logical sub-modules, but
know where to find the functionality you need.
How do YANG model writers
ensure that their models are as easy to deal with as possible by
having consistent modelling approaches for config?
Hmm, your question contains the answer; that's cheating ;-)
Shouldn't the question be:
How do YANG model writers ensure that their models are as easy to
deal with as possible?
The answer to this one is the same as to the question how do a C
programmer ensure that his program is as easy to deal with as
possible?
How do I write code that is generally easy to deal with? Follow
conventions that generally tell me where to put stuff, and how to name
it. What I don't understand is why model-structure or opstate is
actually different to defining such conventions?
2) As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want, given there is no currently defined structure?
Again your question is biased... shouldn't it be:
As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want?
And the answer to this one is the same as to question 1 - I don't
think your proposal solves this, and the solution is that you need to
find these other modules.
Structure really helps me here, since when someone creates a module that
wants to reference a particular type of function, then we reference a
well-known path for that. If someone adds a function of that type, it
must sit in that path so it can be referenced. See the VRRP example I
wrote out before.
“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.
But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem? I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right? How do I know what these other modules are?
Now, I should add that the way I see your solution is a YANG module
that defines a structure of NP-containers. You (or was it Anees?)
then mentioned that we shouldn't focus so much on the *YANG module*;
it was the structure that was important.
First off, we drew a picture [0] that showed the set of modules that we
figured we might need. These break down into various bits of device
functionality. To make this more accessible as something that could be
shown in a draft, we expressed it in YANG and used pyang to draw out the
tree.
The layout of the sets of functions that we have, and how they are
grouped, is the important thing. The fact that we are configuring a
device makes /device a good starting point. I think this is how you
implemented NEDs in NCS too...?
Cheers,
r.
[0]: http://rob.sh/files/model-structure.pdf
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
