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 https://www.ietf.org/mailman/listinfo/netmod
