Subject: Gen-art LC review: draft-mm-netconf-time-capability-05

From: Robert Sparks <[email-masked]>
Date: Wed, 08 Jul 2015 16:39:56 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-mm-netconf-time-capability-05
Reviewer: Robert Sparks
Review Date: 8 Jul 2015
IETF LC End Date: 29 Jul 2015
IESG Telechat date: not yet scheduled

Summary: This draft has open issues to address before publication

This draft adds two separable concepts to netconf
* Asking for and receiving knowledge of when a command was executed
* Requesting that a command be executed at a particular time

The utility of the first is obvious, and I have no problems with the 
specification of that part of this extension. Would it be better to pull 
these apart and progress them separately?

The utility of the second would be more obvious if the draft didn't 
limit the time to be "near future scheduling". It punts on most of the 
hard problems with scheduling things outside a very tight range (15 
seconds in the future by default), without motivating the advantages of 
saying "wait until 5 seconds from now before you do this".

So:

Why was 15 seconds chosen? Could you add a motivating example that shows 
why being able to say "now is not good, but 5 seconds from now is 
better" is useful? (Something like having a series of things happen as 
close to simultaneously without the network delay of sending the 
requests impacting how they are separated perhaps?)

Given the punt, why isn't there a statement that sched-max-future MUST 
NOT be configured for more than some small value (twice the default, or 
30 seconds, perhaps), especially while this is targeted for 
Experimental? Without something like that, I think the document needs to 
talk about more of the issues it is trying to avoid with longer term 
scheduling, even if it doesn't solve those issues. (If I have a fast 
pipe, I can make a server keep a lot of queued requests, eating a lot of 
state, even if the window is only 15 seconds. Pointing to how netconf 
protects against state-exhaustion abuse might be useful).

The security considerations section talks about malicious parties 
attempting to cause sched-max-future to be configured to "a small 
value". Could you more clearly characterize  "small", given that the 
default is 15 seconds?

Even with the near-future limit, there are issues to discuss introduced 
with the ability to cancel a request:

* What prevents a 3rd party from cancelling a request? I think it's only 
that the 3rd party would have to obtain the right id to put in the 
cancel message. If so, the document should talk about how you keep 
eavesdroppers from seeing those ids, and that the servers that generate 
them should make ids that are hard to guess.

* Especially given the near-future limitation, you run a high risk that 
the cancel arrives after the identified request has been executed. It's 
not clear in the current text what the server should do. I assume you 
want the server to reply to the cancel with a "I couldn't cancel that" 
rather than to do something like try to undo the request. The document 
should be explicit.

* The document should explicitly disallow adding <scheduled-time> to 
<cancel-schedule>

One editorial comment: It would help to move the concept of the 
near-future limitation much earlier in the document, perhaps even into 
the introduction and abstract.

And for the shepherding AD: The document has no shepherd or shepherd 
writeup. While a writeup is not required, one would have been useful in 
this case to discuss the history of (lack of) discussion of the document 
on the group's list and the group's reaction to progressing as 
Experimental as an Individual Submission.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Jul 2015 09:23:16 -0700

On Wed, Jul 8, 2015 at 2:39 PM, Robert Sparks <[email-masked]> wrote:

> The utility of the second would be more obvious if the draft didn't limit
> the time to be "near future scheduling". It punts on most of the hard
> problems with scheduling things outside a very tight range (15 seconds in
> the future by default), without motivating the advantages of saying "wait
> until 5 seconds from now before you do this".
>
> So:
>
> why being able to say "now is not good, but 5 seconds from now is better"
> is useful? (Something like having a series of things happen as close to
> simultaneously without the network delay of sending the requests impacting
> how they are separated perhaps?)
>
> Given the punt, why isn't there a statement that sched-max-future MUST NOT
> be configured for more than some small value (twice the default, or 30
> seconds, perhaps), especially while this is targeted for Experimental?
> Without something like that, I think the document needs to talk about more
> of the issues it is trying to avoid with longer term scheduling, even if it
> doesn't solve those issues. (If I have a fast pipe, I can make a server
> keep a lot of queued requests, eating a lot of state, even if the window is
> only 15 seconds. Pointing to how netconf protects against state-exhaustion
> abuse might be useful).
>
>

Picking some arbitrary small sched-max-future value only lowers the
probability that
something goes wrong, so it is not a very good punt.

> attempting to cause sched-max-future to be configured to "a small value".
> Could you more clearly characterize  "small", given that the default is 15
> seconds?
>
> that the 3rd party would have to obtain the right id to put in the cancel
> message. If so, the document should talk about how you keep eavesdroppers
> from seeing those ids, and that the servers that generate them should make
> ids that are hard to guess.
>

Since the scheduled rpc event is sent to every client that is listening
for notifications, there is no possibility for security through
hard-to-guess token,
as is done with the "persist-id"  for cancelling a confirmed-commit.

NETCONF has no support for sending a notification to just 1 session or user.

> the cancel arrives after the identified request has been executed. It's not
> clear in the current text what the server should do. I assume you want the
> server to reply to the cancel with a "I couldn't cancel that" rather than
> to do something like try to undo the request. The document should be
> explicit.
>
> near-future limitation much earlier in the document, perhaps even into the
> introduction and abstract.
>
> this case to discuss the history of (lack of) discussion of the document on
> the group's list and the group's reaction to progressing as Experimental as
> an Individual Submission.
>
>

Andy