Telechat Review of draft-mm-netconf-time-capability-08
review-mm-netconf-time-capability-08-genart-telechat-sparks-2015-12-14-00

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.