On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton <[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! > > The "old manager/new agent" problem has been around for at least 3 decades. Experience has shown that adding new features in a way that does not break existing deployments requires forethought and planning. The backward compatibility requirement is not hard to meet. Simply require the client to opt-in to the new behavior. That's it. Problem solved. > Thanks, > Rob > > >> Andy > 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
