> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman <[email protected]> wrote:
>
>
>
> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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 ([email protected]
> <mailto:[email protected]>) 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.
>
>
> Sorry -- are you suggesting that maybe /device adds no value beyond /?
> If so, I agree.
>
>
>> 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?
>
>
> RTFM
Andy,
While it might be frustrating, coming to an understanding of what the
problem is or might be, and then looking at
why the existing mechanisms/models or additional ones solve these requirements
(or do not) is what is at hand. I think everyone agreed
at the interim meeting that the requirements were clear and sound. This is
detailed in the meeting minutes. If anyone disputes this,
I am happy to do an official WG call for consensus on these specifics, but
given the unanimous agreement at the meeting, I did
not feel that it was necessary to do this. Based on that, the next question
is: are these problems solved with what is here today,
or do we need another approach/es. Rob is clearly not an idiot and is asking
for detailed reasons why you and others
believe what he/OpenConfig have proposed is insufficient. Please be as
considerate and constructive as he has been in asking his
questions when you address them.
—Tom (Speaking as Co-chair)
> 2) As a creator of YANG mode
>
> ls, 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?
>
>
>
> The modules you are using have data locations defined.
> In order to define YANG data (with YANG 1.0 or 1.1)
> a top-level data node or augment-stmt will be present specifying the
> /path/from/root
>
> How do you know where data is that has not been defined yet?
> You don't and YANG has no ability to reference undefined data anyway.
>
>
> “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.
>
>
>
> Why isn't RTFM good enough?
> Is there some expectation that just /the/path/from/root is enough
> to make somebody an expert in managing some feature or an expert
> in writing new YANG modules?
>
> Additional tools outside the scope of IETF standardization work are needed
> to make development easier.
>
> Nothing whatsoever is stopping the routing area from defining some structure
> for new modules. Pick whatever you like.
>
> The only pushback is wrt/ obsoleting existing RFC modules and moving the
> data nodes in them to a different location. Some of us do not agree that
> a problem has been demonstrated that warrants starting over for these RFCs.
>
>
> 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.
>
>
> Andy
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
