Hi, I am not commenting on the solution proposals. The document being discussed is the requirements document. I agree with Juergen that backward compatibility needs to be an explicit requirement. Are you objecting to such a requirement?
Andy On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton <[email protected]> wrote: > Hi Andy, > > Please can you let me know whether you think that any of the three > proposed solutions wouldn't meet this backwards compatibility requirement? > > draft-kwatsen-netmod-opstate-00 has some features that might be generally > useful to NETCONF, like adding <get-state> support as defined in section > 5.1, that I would expect could just be added to a future version of > NETCONF. Would a requirement that the solution is backwards compatible > with existing implementations require that support for <get-state> must > always be optional? Or could a new version of the NETCONF protocol require > that support for <get-state> is required? > > Thanks, > Rob > > > On 17/12/2015 16:06, Andy Bierman wrote: > > Hi, > > I agree with Juergen that this should be clear. > It was discussed several times. All existing protocol > functionality for NETCONF and RESTCONF MUST continue to work > for clients which do not choose to examine the differences between > intended config and applied config. > > > Andy > > > On Thu, Dec 17, 2015 at 6: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 >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > netmod mailing [email protected]https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
