On Mon, Feb 8, 2016 at 9:56 AM, 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. 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. > >
This solution assumes that the overhead of retrieving data (while the server is applying config) does not impact performance. IMO retrieving 2 separate data trees and comparing them on the client uses a lot of bandwidth and it makes the server even more busy, so applying the config will take even longer. The only solution possible by replicating the YANG objects would be to retrieve both trees and compare them on the client. I prefer a solution that does not involve any polling by the client, such as a notification based solution. Since operations are data-driven in YANG, implementing a new RPC is the same cost as implementing new YANG data nodes. Andy > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
