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

Reply via email to