What text do we agree to put into draft-chairs-netmod-opstate-reqs? I maintain that we need definitions for the terms "synchronous" and "asynchronous". Robert took a stab at defining these terms on the 24th (thanks Robert!), but so far no one has commented on them. So I don't think we're ready to close this issue yet.
Thanks, Kent From: Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>> Date: Tuesday, September 29, 2015 at 10:56 AM To: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) Robert, It seems this discussion has run out of steam and we've come to a head on this issue. It seems we have some actions we can take based on the list of three bullets below as part of that conclusion (potentially). Do folks think we are ready to close this issue down officially? -Tom On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: On 28/09/2015 18:17, Andy Bierman wrote: On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Andy, On 24/09/2015 19:22, Andy Bierman wrote: Hi, I find this exercise to classify servers as synchronous or asynchronous mostly useless. We have both types of instrumentation in our server. They can be different on a per-node basis. They can both take a long time or both be instant, depending on the instrumentation code the vendor writes. In any case, the server does not know if the instrumentation has finished making the network behave according to the new edit. That would be new functionality that no vendor supports at this time. Currently servers return "ok" if the edit is accepted into the running datastore. There are no other semantics wrt/ returning "ok". I'm not sure whether we agree here, but as stated previously, Sec 5.1 of RFC 6241, implies that if the configuration is in the running datastore then that configuration is expected to be active on the device. I do not agree at all that the running datastore means anything other than the intended confg. A new operation is needed to retrieve the active config vs. the intended config. If the running datastore only ever means intended config, then I think that would imply: - existing NETCONF servers should reply immediately after the config has been semantically verified + written to the config subsystem before the configuration is applied. - existing NETCONF servers are logically classified (as per openconfig-netmod-opstate) as being asynchronous w.r.t to the config requests. - the existing NETCONF/RESTCONF protocols has no direct mechanism for indicating a failure to apply any configuration leaf, the only way such information could be deduced is through related operational state leaves or notifications. Rob _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
