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. the motivation in this case is that users are saying that the current solution is inadequate. 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. But it's also clear that some in the WG would prefer Option 2 (and most/all of these are its coauthors.) 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. 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
