Hi, I think the current operations need to continue to work. With the current <edit-config> or <commit> the client does not know if the server applied the config or just accepted the request.
With the new solution, I expect that a client that does not explicitly ask for "wait until applied" will get the old (unspecified) behavior. Andy On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton <[email protected]> wrote: > Hi Andy, > > Thanks for resending and apologies for missing it earlier. > > 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. > > However, this requires all opstate aware servers: > - To handle a mix of clients, some of which are opstate aware, and some > that are not. > - To potentially handle a mix of requests, some of which are opstate > aware requests, and some are not. > > It also prevents: > - Having a server that is implemented to only support opstate aware > clients. > - Having a server side configuration knob to control the behaviour (since > it would affect the semantics for all clients). > > > Personally, I think that the best solutions will likely meet your proposed > requirement below, but I don't agree that it should be mandated, even > though I agree that it is something that the solution should aim for. > > Changing the MUST to SHOULD would make the requirement fine with me ... > > Finally, regarding your example below, I didn't think that the existing > NETCONF protocol semantics specify exactly when the server is required to > respond to the client, and hence blocking the client until the > configuration has been applied would be a valid edit-config implementation > under the existing NETCONF specification. > > Thanks, > Rob > > > On 17/12/2015 18:26, Andy Bierman wrote: > > 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]> >> [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
