> On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman <a...@yumaworks.com> wrote:
>
>
>
> On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas <tnad...@lucidvision.com
> <mailto:tnad...@lucidvision.com>> wrote:
>
>> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman <a...@yumaworks.com
>> <mailto:a...@yumaworks.com>> wrote:
>>
>>
>>
>> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <r...@rob.sh
>> <mailto:r...@rob.sh>> 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 (a...@yumaworks.com
>> <mailto: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.
>>
>>
>> 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.
>
>
> Are you suggesting that the openconfig drafts offer some solution
> to "how do I use this YANG module" that does not involve reading the YANG
> module?
> If so, I didn't see it. Please point it out to us.
I am not taking sides. I hope I don’t need to point out these guys have
presented an alternative
solution. The WG must consider this seriously as it is a serious proposal that
is being seriously
considered in other parts of the IETF such as the routing area. I will point
out again that we are
looking at this closely and thoroughly. If its determined to be desired via
consensus,
then we will go forward with it; if not, then no. Its my action and job to
determine this and I’ve
outlined the process for this.
> My only objection is to moving data that has already been published in an RFC.
> I am not the only person on this list that has questioned to value of
> moving this small number of data models to new roots in the data tree.
>
> Everything done in an IETF meeting needs to be confirmed on
> the mailing list. You know that.
>
> So what specifics are you ready to declare have WG consensus?
Again, my assumption was that there was sufficient consensus and
understanding around
the requirements (not the solutions) after the interim meetings. I explicitly
asked that
question at the meeting and went around the WebEx call to confirm. Those
conclusions were
documented in the meeting minutes posted on the list.
—Tom
>
>
>
> —Tom (Speaking as Co-chair)
>
>
>
> Andy
>
>> 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
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>> <https://www.ietf.org/mailman/listinfo/netmod>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
