Hi, I already did that:
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. > > Another way to put it: The client MUST choose to participate (opt-in). An example of a solution that meets this requirement - The client adds a <wait-until-applied /> flag to an edit-config request which causes the server to wait until the edit is applied before returning <rpc-reply>. This requires the server to opt-in for the wait, and it is not forced on the client. Andy On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton <[email protected]> wrote: > Hi Andy, > > Please can you state the specific text that is being proposed to be added > as a new requirement? > > Thanks, > Rob > > > On 17/12/2015 17:33, Andy Bierman wrote: > > 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]> >> [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
