Andy,

Apologies, I don’t understand how your mail answers the questions that I posed.

On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com) wrote:

A whole lots of words here, but I am still confused why /device is better than /
for solving your "data model awareness" problem.
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.

I’m not sure how this could be clearer.

YANG is no different than any other part of the source code.
Reusable YANG is just as likely or unlikely as reusable C,
depending on how aware people are of the existing code base.

Which OAM? Read the modules and decide. No magic there.
How would /device vs / (as the first node) help you figure this out?

Nobody is objecting at all to creating structure for the new modules.
If /device has siblings, then let's see them in the uber-tree.
The objection is to adding in a useless layer, and moving existing
data nodes, which breaks existing implementations of all those data nodes.
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? How do YANG model writers ensure that their 
models are as easy to deal with as possible by having consistent modelling 
approaches for config?

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?

“Just read through the modules” is not acceptable answer when considering 
making things easy to use for YANG model consumers. I want to have things that 
are logical to humans such that they can easily adopt YANG-based netmgmt. If 
they need to adopt the ecosystem by having to use hodgepodge approaches, then 
this feels like we are fundamentally missing an opportunity to simplify things.

I want to make sure that we DO have re-usable YANG - like we have re-usable 
code elsewhere. In my experience this is done elsewhere by defining conventions 
that ensure that this is the case. 

Regards,
r.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to