Thanks Andy -- It seems to me that there are aspects of your comments that apply to each...
Lou On 2/8/2016 3:29 PM, Andy Bierman wrote: > Hi, > > > I was commenting on solution 1. > > > Andy > > On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > > <mailto:[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]> > > <mailto:[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]> > > <mailto:[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]> > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
