On Wed, Jul 8, 2015 at 2:39 PM, Robert Sparks <rjsparks@nostrum.com> 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).
>
>

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



> 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.
>


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.



> * 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.
>
>

Andy