Re: [Gen-art] Gen-art LC review: draft-mm-netconf-time-capability-05

[Tal Mizrahi <[e-mail]>]

Hi Andy,

We appreciate the detailed review.

>The draft adds the invoke-at-time capability to a small set
>of NETCONF operations (via augment-stmt).
>The mechanism cannot be used for any other operations.
>It appears this is the entire list of operations supported:

>   - get-config
>   - get
>   - copy-config
>   - edit-config
>   - delete-config
>   - lock
>   - unlock
>   - close-session
>   - kill-session
>   - commit

>Why was this subset of all operations selected?

This list contains most of the RPCs defined in RFC6241, with the exception of three RPCs: cancel-commit, validate, and discard-changes. It did not make sense to us to support the <scheduled-time> element for these RPCs.
The intended status of this document is experimental. For experimental purposes, it appears that this list of RPCs is sufficient. However, if you feel that there is an RPC that needs to be added to the list please let us know.


>I cannot find any text in the draft that says what happens
>if the client session terminates for any reason.  

(*) Agreed. We will add text that says that when a session terminates, the server cancels all scheduled RPCs that were received in that session.

>There are
>commands that support the 'execution-time' parameter
>like <lock> that explicitly require a session to be maintained.
>Not sure a delayed <close-session> even makes sense.

Agreed. We will remove the <close-session> RPC from the YANG module.

>If the session is gone when the scheduled operation is about
>to be executed, does the server cancel it or attempt it?
>Without a session, the server cannot send an <rpc-reply>,
>so it should not attempt the command.

Agreed. See the response to (*) above.

>What if commands are scheduled at the same time?
>Is the server expected to serialize these commands or
>invoke them in parallel?  Note that operations within
>a single session MUST be invoked in order, but this only
>seems to apply to the original <rpc> to schedule the delayed
>operation.

Good point. Scheduled RPCs should be processed serially, as is currently defined in RFC 6241. If two or more scheduled RPCs have the same <scheduled-time> the server can process them in an arbitrary order.
We will add text that clarifies this in the draft.


>I think this draft is severely constrained by RFC 6241, sec. 4.5.

>4.5.  Pipelining

>   NETCONF <rpc> requests MUST be processed serially by the managed
>   device.  Additional <rpc> requests MAY be sent before previous ones
>   have been completed.  The managed device MUST send responses only in
>   the order the requests were received.

Yes, the PURPOSE of the :time capability is to allow RPCs to be executed according to their scheduled time, and not according to their reception order. 
I suggest that we add some text that clarifies that replies to scheduled RPCs are sent in the order of their schedule, while replies of unscheduled RPCs (as defined in RFC 6241) are sent by the reception order of the corresponding RPCs.

>There are no existing NETCONF servers that will start processing rpc(N+1)
>while rpc(N) is in progress for a session.  It might violate the MUST
>in sec. 4.5.

Indeed, that is the behavior of *existing* servers, but this does not impose an interoperability problem with the :time capability. As all capability-based extension, interoperability with *existing* servers is guaranteed by the capability exchange: a server that does not support the :time capability will continue to send RPC replies according to their arrival order. A server that supports the :time capability will perform (and reply to) scheduled RPCs according to their schedule, and unscheduled RPCs according to their reception order.  

The :time capability must be:
1. Interoperable with existing servers by means of the capability exchange (we believe this is currently satisfied).
2. Well defined.
To guarantee (2), I suggest that in the capability definition (section 4) we will clarify how the :time capability affects the order of RPC replies of scheduled RPCs.

>A different NETCONF session is required for each scheduled operation.
>Only 1 scheduled operation can be pending on each session.
>A different session is also required to receive the <netconf-scheduled-message>
>since the session sending the scheduled operation is busy waiting for the
><rpc-reply>.  The <cancel-schedule> RPC also must be on another session,
>for the same reason.

If I understand correctly, you are suggesting a workaround that allows the :time capability without violating the reply-in-reception-order requirement. Right?

Thanks,
Tal.