On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote: > > > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen <[email protected]> > > wrote: > > > > > > > > > > > > > >>>> I’m struggling a bit to understand what is motivating you to ask this > >>>> question. That is, as a tool vendor, I wouldn’t think that any > >>>> decision made here would affect you immediately. My expectations are > >>>> that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, > >>>> such that implementations would only opt-in when needed - a pay as you > >>>> grow strategy. But herein perhaps lies an unstated requirement, that > >>>> the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible > >>>> with respect to existing deployments. Did we miss it or is it too > >>>> obvious? > >>>> > >>> > >>> It may be obvious for many of us but for the sake of completeness I > >>> prefer to have this backwards compatibility assumption explicitely > >>> stated. > >> > >> +1 > > > > > > [as a chair] > > > > As last call comment, there seems to be support for adding a requirement to > > the opstate-reqs draft to state that solutions supporting said requirements > > MUST be backwards compatible with respect to existing deployments. Do we > > have WG consensus to add this as a requirement to this draft? Are there > > any objections? Please voice your opinion before the last call cutoff date > > (Dec 30). > > > > > > [as a contributor] > > > > > > I’m unsure if it makes sense to call it out in this draft, in that it seems > > universally applicable, but I don’t see any harm in it either and thus do > > not object. > > > > > > Kent > > [As Co-chair] > > Given the tall hill we climbed to get to this point on the > requirements, I > want to be clear that there needs to be very significant support to change > the requirements > in any significant way. We went round and round the drain on settling on > these requirements, and > people had a whole host of reasonable opportunities to add this during those > times. I want to point out that while this statement may seem subtle, > slipping this in at the last minute could have a profound impact on solutions > built from these requirements, so I want to be sure everyone involved has > through through this kind of change. > > —Tom
Tom, I think Andy is talking about applicability - to which kind of servers do these requirements apply. For example, if it takes more time on a certain class of devices to retrieve the difference between applied and intended config than it takes to turn intended config into applied config, then these requirements may not be applicable (since by the time you have finished retrieving the difference it has vanished). Andy, did I get this right? /js -- 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] https://www.ietf.org/mailman/listinfo/netmod
