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? > 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. > 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. > 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. /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
