On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen <kwat...@juniper.net> wrote:
> > Hi Robert, > > I agree that -01 doesn’t add much on top of -00. This is expected as > we’re in the fit and finish phase. If you want to help finish the draft, > then please consider responding to one of these threads: > > http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html (re: > rollback-on-error) > http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html (re: > model-structure) > > As for this thread: > > 1. Regarding adding an explicit backwards-compatibility requirement, > please note that what was written here is still in effect: > http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html. Note > that no objections have been raised yet, so this will likely happen. > > 2. Regarding adding an applicability statement, there is currently only > one voice asking for it, which isn’t enough to warrant a change. > > I did not ask to add an AS to the charter. I don't think the WG agrees enough on the problem to write such a document. > Thanks, > Kent > Andy > > > > On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" < > netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote: > > >Hi, > > > >On 17/12/2015 23:45, Randy Presuhn wrote: > >> Hi - > >> > >>> From: Robert Wilton > >>> Sent: Dec 17, 2015 1:12 PM > >>> To: Andy Bierman > >>> Cc: "netmod@ietf.org" > >>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 > >> ... > >>> Your requirement is a bit too strong for my liking. > >>> > >>> To paraphrase your requirement text, it is forcing that all > >>> compliant NETCONF/RESTCONF servers MUST support any clients that > do > >>> not want to differentiate between intended config and applied > >>> config. > >> Do do otherwise sound to me like an interoperability disaster, > >> and would encourage the "siloization" of toolsets. > >> > >>> However, this requires all opstate aware servers: > >>> > >>> - To handle a mix of clients, some of which are opstate aware, > and > >>> some that are not. > >> This seems perfectly reasonable. To do otherwise torpedoes the very > >> notion of interoperability. > >> > >>> - To potentially handle a mix of requests, some of which are > >>> opstate aware requests, and some are not. > >> Ditto. > >> > >>> It also prevents: > >>> > >>> - Having a server that is implemented to only support opstate > aware > >>> clients. > >> Avoiding the creation of such servers sounds like a *good* thing to me. > >> > >>> - Having a server side configuration knob to control the > behaviour > >>> (since it would affect the semantics for all clients). > >> This also sounds like something which it would be desireable to prevent. > >> > >> I think I'm squarely with Andy on this one. > > > >Taking a step back ... > > > >I am probably way off the mark, but my perception is that some (perhaps > >many) of the folks in the WG still perceive that the opstate > >requirements are niche requirements for some unusual scenarios, and that > >everyone else is happy with the status quo and don't want/need them. > > > >Alas, I don't share that view. For me, the opstate requirements can be > >summarized as saying that the operators just want to know what > >configuration the device is actually running in a format that is > >convenient for them to use. This really doesn't appear to be > >unreasonable request to me, and if I was writing to a network > >manageability API then I would choose to use opstate because I perceive > >that it is a more robust and easier to use API. The counter arguments > >appear to be that it is too hard for devices to provide this > >information, and that the operators have historically managed without it. > > > >However, I think that several things have changed, and hence negate > >these counter arguments: (i) the operators want to have much more > >automation and management over their devices, (ii) they have found a way > >to group together and have a more vocal voice about what they need and > >want, (iii) the operators have realized that they don't need to wait for > >the SDOs and can create defacto standard models on their own if they > >have to. > > > >Personally, I would like us to stop spending time churning on the > >requirements and actually get on to discussing the solutions. To be > >honest, there has been relatively little change in my understanding of > >the requirements from reading draft-openconfig-netmod-opstate-01 back in > >July, and I was expecting to discuss the solution drafts back in > >September. Here we are in December, and I'm not convinced that we have > >truly made significant progress. > > > >The only reason that I submitted a solution draft to this problem was > >because I thought it unlikely that OpenConfig would support a multiple > >datastore solution, and I could see strong resistance amongst the IETF > >engineers to the proposed OpenConfig solution. I was hoping that my > >proposed solution might be seen for the compromise that it is between > >the two opposing positions. But I care less on what the solution is, > >and more whether we can agree on one and move forward. > > > >As someone that is quite new to SDO processes, my main concern is that > >IETF (and other standards bodies) are moving too slowly here, and that > >by the time that IETF have produced a sufficiently complete set of YANG > >models to manage network devices it will be too late because the > >industry will already have converged on the OpenConfig models, which > >although not perfect, are close to being usable now, and are being > >evolved at a much quicker pace ... > > > >So my hope for the early new year is that we can reach common ground > >with OpenConfig and converge on a single set of YANG modules for > >managing network devices, and that includes having a solution to the > >Opstate problem. > > > >Finally, if my acquiescing to Andy's requirement is helpful to move this > >process forward then that is fine with me. As I have previously > >indicated, I don't really think that it helps with framing or discussing > >the solutions, but equally I can live with it since I suspect that the > >solutions are likely to comply with it anyway. > > > >Apologies for the long email, and given I may not be actively reading > >the WG emails over the next couple of weeks, I'll wish you all happy > >holidays! > > > >Thanks, > >Rob > > > >> > >> Randy > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> . > >> > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
