Hi Andy, Thanks for the very good comments.
Which solutions(s) were you commenting on -- you say "this" so is ambiguous. Lou On 2/8/2016 2:17 PM, Andy Bierman wrote: > > > On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[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] <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
