Martin,
Thanks for the response. See below.
On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
> Hi,
>
> Lou Berger <[email protected]> wrote:
>> Hi Juergen, (All)
>>
>> I've change the subject line as I'm really commenting on all three
>> documented options in this message.
>>
>> On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
>> <[email protected]> wrote:
>>
>>> Lou,
>>>
>>> there are things I find fundamentally flawed and things I find
>>> somewhat flawed. I do not understand why we need to mess around with
>>> data encodings at all. I do not see what gets simpler by messing
>>> around with the data encodings. Engineering decisions are usually
>>> cost/benefit tradeoffs.
>> I completely agree with this statement, as a general statement.
> I agree with Juergen - I read his statement to be about Robert's
> proposed solution.
>
>> the
>> motivation in this case is that users are saying that the current
>> solution is inadequate.
> Which solution is the current solution?
anything in an rfc or soon to be an rfc. IMO.
>
>> I think it behooves us to listen and see if a
>> better tool can be provided that addresses the limitations raised.
>>
>>> I see the costs, I am unsure about the
>>> benefits.
>>>
>> I think this is a question of perspective. I get that from a protocol
>> standpoint, and possibly even language standpoint, why this discussion
>> can be considered unneeded complexity. I wouldn't even be surprised if
>> the open config folks agreed with you, as the core of their solution
>> really doesn't need changes to the underlying protocol or language.
>>
>> As I see it, there are three options on the table to address the core
>> issue of OpState:
>>
>> 1. Do nothing in Netconf / restconf or yang, and leave it to model
>> conventions = openconfig draft
>>
>> 2. Extend Netconf / restconf , but not yang or models = Kent's draft
>>
>> 3. Use a language / tools based approach to augment models and
>> automatically produce a form of option 1 style convention changes,
>> without model definition restrictions. ~= Rob's draft (I'll assume
>> changes previously discussed on list)
>>
>> WRT 1: We've heard from the model development community, i.e. model
>> writers, that 1 is doable but painful and easily done incorrectly. It
>> also impacts other SDOs, i.e. non ietf model writers.
>>
>> WRT 2: We heard from the user community, at least a small number of
>> representatives, that 2 alone doesn't address their needs.
> We have heard from the open config people that their proprietary
> protocol does not support datastores, but no more details.
I think I've heard users say what they believe is true from their
perspective and context. I've heard others say we disagree (or stronger
statements.)
>> But it's
>> also clear that some in the WG would prefer Option 2 (and most/all of
>> these are its coauthors.)
> This was the preferred solution of the room in Yokohama. 2 of the 4
> authors were present.
sure. And we know that the IETF consensus is not judged by who is in
the room. It is of course useful information to the WG and the chairs.
>> WRT 3: There's some discussion on how/if Option 3 might best meet the
>> user requirements. I think focusing on this approach on the list could
>> be helpful.
>>
>> One question I have for you, Juergen, and the other authors of 2 is if
>> there are changes/improvements to 3 that you/the can see that would make
>> acceptable? Note I am NOT asking which the authors prefer as this is clear.
> I think this solution is pretty messy. Also, it is unclear to me how
> it affects things like filtering and access control for example. Can
> instance-identifiers all refer to these auto-generated nodes; are
> these nodes really part of the model or not? How is partial locking
> affected? There are lots of details to work out.
This is useful comments and would like to see what the options
are/should be WRT Option 3. Do you have any opinions on this?
Thanks,
Lou
>
>
> /martin
>
>
>
>> For the authors of 1, I think it would be worth hearing if a
>> language/tools based approach to populating the Applied Configuration
>> information is workable for them.
>>
>> Lou
>>
>>> /js
>>>
>>> On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
>>>> Juergen,
>>>>
>>>> How do you feel about the proposed modification on the table? (Leaving the
>>>> model defined config leaves untouched and adding a -CFG or -metadata
>>>> sibling node which would contain the additional automatically generated
>>>> leaves.)
>>>>
>>>> Lou
>>>>
>>>>
>>>> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
>>>> <[email protected]> wrote:
>>>>
>>>>> On Fri, Feb 05, 2016 at 10:09:37AM +0000, Robert Wilton wrote:
>>>>>> Hi Juergen,
>>>>>>
>>>>>> I don't really follow your point.
>>>>>>
>>>>>> The solution is fully backward compatible - in that only clients that
>>>>>> make use of the protocol extension would see the new encoding. Existing
>>>>>> clients would continue to see the encoding as directly defined in the
>>>>>> YANG schema, and a server would be able to support old and new clients
>>>>>> concurrently.
>>>>>>
>>>>> The YANG RFC details how data is encoded in XML. People have written
>>>>> and deployed code against based on this RFC. I do not accept an
>>>>> approach where an RPC option can simply request that the encoding
>>>>> defined in the YANG RFC is ignored and replaced with a very different
>>>>> encoding.
>>>>>
>>>>> /js (stating a clear opinion as a technical contributor)
>>>>>
>>>>> --
>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>
>>> --
>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
