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. Thanks, Kent 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
