[Gen-art] Gen-art Telechat review: draft-mm-netconf-time-capability-08

[Robert Sparks <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

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

Document: draft-mm-netconf-time-capability-08
Reviewer: Robert Sparks
Review Date: 14 Sep 2015
IETF LC End Date: past
IESG Telechat date: 17 Sep 2015

Summary: Ready for publication as an Experimental RFC

The changes since -05 address my concerns with allowing cancels to be 
scheduled, and dealing with cancels not being processed in time.

The added discussion on how to choose a max-sched-future value is good. 
I still would have preferred a hard limit for this experimental period.

The addition of cancelling all pending commands when the submitters 
connection closes is a good one.

The document doesn't reflect the email discussion we had around how 
certain 3rd parties can cancel commands. I encourage adding at least a 
sentence reminding implementers and experimenting operators to remember 
that they can.

RjS


On 7/8/15 4:39 PM, Robert Sparks wrote:
> 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.