Hi Rob, Thanks for authoring the comprehensive response. I’m in complete agreement and support publication of the document. Thanks, Acee
On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email protected] on behalf of [email protected]> 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: "[email protected]" >>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> . >> > >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
