Hi Andy,
Thanks for the comments.
We have posted an updated version of the draft:
https://tools.ietf.org/html/draft-mm-netconf-time-capability-06
We believe the current draft addresses the issues you raised below.
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.
Right, we have added a paragraph to Section 6.2 that explains this issue.
BTW, we discussed the same issue in another thread:
https://www.ietf.org/mail-archive/web/ietf/current/msg94144.html
Picking some arbitrary small sched-max-future value only lowers the
probability that
something goes wrong
Right, the low value of sched-max-future lowers the probability, but does not
prevent something wrong from happening. In the current draft this is more
clearly explained and discussed in Section 3.6.
Please let us know if you have further comments.
Thanks,
Tal.
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Andy Bierman
Sent: Friday, July 10, 2015 7:23 PM
To: Robert Sparks
Cc: General Area Review Team; ietf(_at_)ietf(_dot_)org;
draft-mm-netconf-time-capability(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: Gen-art LC review: draft-mm-netconf-time-capability-05
On Wed, Jul 8, 2015 at 2:39 PM, Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com<mailto:rjsparks(_at_)nostrum(_dot_)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