On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman <a...@yumaworks.com> wrote:
> 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 <rwil...@cisco.com> 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. >> >> This is simple to achieve by adding optional parameters that a new client will set and an old client will not know about. > 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). >> >> Not true, since the current RFC behavior is undefined. A server vendor can choose right now to only return <rpc-reply> after all intended is applied. The new feature will be that a client can explicitly request this behavior and a compliant server will support it. If the client does not request it, then there is a chance that operations will time out that did not use to time out. This will be very visible and disruptive to operators, and perceived as a bug. > >> 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. >> > Yes it would be valid, but it might generate unhappy customers with broken client applications just the same. > >> Thanks, >> Rob >> > Andy > >> >> 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 <rwil...@cisco.com> >> 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 < <rwil...@cisco.com> >>> rwil...@cisco.com> 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 < <kwat...@juniper.net> >>>> kwat...@juniper.net> 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 >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing >>>> listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>>> >>>> >>>> >>> >>> >> >> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
