On Wed, Jul 8, 2015 at 2:39 PM, Robert Sparks <rjspa...@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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
