Hi Rob, [I am replying to this email since you have your two issues clearly enumerated here; thanks for doing that]
[side note: the text versions of your replies are very difficult to read and thus reply to; your mail client doesn't quite get the citation right. is there any knob you can tweak to improve that?] Rob Shakir <r...@rob.sh> wrote: > Please re-read my email - here’s the single statement where I said > that this > was NOT the discussion that I think is important: > >>> It strikes me that there is a need to take a step back from the debate >>> of whether /device is a good idea or not. Ok, I will try to do that. > Please suggest an alternate approach to the one that is laid out in > draft-openconfig-netmod-model-structure that you believe will help > with the two > problems that I raised. I’ll rephrase them here with less explanation, > albeit > that comes with less clarity. > > > 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. This is a hard problem to solve. It is similar to the problem of finding the correct linux package that solves a given problem. In some cases I can search a central registry (package manager), and in some cases I have to expand the search. One solution is to not allow extensible modules at all; instead we would work with ONE model that we just add to over time, and republish this ever growing module when we need to. Vendors and other SDOs would not be able to add to this single module. I don't think this is a realistic approach. Another solution is to try to have some kind of registry of all modules. This might work for IETF modules, but who knows what other SDOs or vendors do? (Incidentally there is such a registry for IETF modules, maintained by IANA (http://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml#yang-parameters-1)) For MIBs, there are sites that try to collect all published MIBs, including vendor MIBs. > 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? > 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. > “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. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
