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 list [email protected] https://www.ietf.org/mailman/listinfo/netmod
