On Sat, Aug 1, 2015 at 11:32 AM, Tal Mizrahi <ta...@marvell.com> wrote:
> Hi Robert, > > Thanks for the comments. > > We have submitted an updated version of the draft, which addresses the > comments we received from you and other reviewers in IETF last call. > https://tools.ietf.org/html/draft-mm-netconf-time-capability-06 > > Our responses to your comments can be found below. > Please let us know if you have further comments or questions. > > Thanks, > Tal and Yoram. > > > > > >-----Original Message----- > >From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Sparks > >Sent: Thursday, July 09, 2015 12:40 AM > >To: General Area Review Team; i...@ietf.org; draft-mm-netconf-time- > >capability....@ietf.org > >Subject: Gen-art LC review: draft-mm-netconf-time-capability-05 > > > >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? > > > > > We believe there is a great benefit to defining these two feature > together, although each of them can be used independently. The second > certainly gains from the first, since the execution-time provides feedback > to the client about the actual time of execution compared to the scheduled > time of execution. > > IMO returning the execution-time is not needed. How far from the requested time do you expect the server to be? Maybe a few milli-seconds? > >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?) > > > > Point well taken. We have added the following example, motivating why near > future scheduling (<15 seconds) can be useful: > > I don't understand the arbitrary 15 sec. limit. What problems magically disappear if the timeout is 14 sec vs. 16 sec.? > A typical example of using near-future scheduling is a coordinated commit; > a client needs to trigger a commit at n servers, so that the n servers > perform the commit as close as possible to simultaneously. Without the time > capability, the client sends a sequence of n commit messages, and thus each > server performs the commit at a different time. By using the time > capability, the client can send commit messages that are scheduled to take > place at time Ts, which is 5 seconds in the future, causing the servers to > invoke the commit as close as possible to time Ts. > > You should pick a different example because the NETCONF confirmed-commit procedure is designed to be loose-coupled. The default timeout is 10 minutes. Since the client needs sessions open with all servers involved in the network-wide commit, there is no advantage in staging the <commit> operations 15 sec. in advance, to make sure the servers are reachable. I thought the synchronized <get> on operational state was a good use-case. Andy > We have also added an explanation of why 15 seconds were chosen as the > default value: > > The default value of sched-max-future is defined to be 15 seconds. This > duration is long enough to allow the scheduled RPC to be sent by the > client, potentially to multiple servers, and in some cases to send a > cancellation message, as described in Section 3.2. On the other hand, the > 15 second duration yields a very low probability of a reboot or a > permission change. > > > >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). > > > > Note that we did not define a maximal value for sched-max-future, since > one of the goals was to define a generic tool that can be used for various > different environments. The draft clearly states the intention of using > near-future-scheduling, but the requirements and constraints of different > environments may require the sched-max-future to have a different value, > potentially higher than 30 seconds. Hence, we prefer not to define a > maximal value. Indeed, in the draft 06 there is a more detailed discussion > about the issues we are trying to prevent by using near-future scheduling > (Section 3.6). > > > >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? > > > > Agreed. > We rephrased this paragraph to be more clear about the "small" value: > > This YANG module defines <sched-max-future> and <sched-max-past>, which > are writable/creatable/deletable. These data nodes may be considered > sensitive or vulnerable in some network environments. An attacker may > attempt to maliciously configure these parameters to a low value, thereby > causing all scheduled RPCs to be discarded. For instance, if a client > expects <sched-max-future> to be 15 seconds, but in practice it is > maliciously configured to 1 second, then a legitimate scheduled RPC that is > scheduled to be performed 5 seconds in the future will be discarded by the > server. > > > >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. > > > > We understand this needs further clarification. As noted by Andy Bierman > in a corresponding mail: > > >>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. > > > We rephrased the paragraph to clarify these issues: > > This YANG module defines the <cancel-schedule> RPC. This RPC may be > considered sensitive or vulnerable in some network environments. Since the > value of the <schedule-id> is known to all the clients that are subscribed > to notifications from the server, the <cancel-schedule> RPC may be used > maliciously to attack servers by canceling their pending RPCs. This attack > is addressed in two layers: (i) security at the transport layer, limiting > the attack only to clients that have successfully initiated a secure > session with the server, and (ii) the authorization level required to > cancel an RPC should be the same as the level required to schedule it. > > > > >* 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> > > > > > > Agreed. > We have addressed these two comments by adding the following paragraph: > > A cancel-schedule message MUST NOT include the scheduled-time parameter. A > server that receives a cancel-schedule should try to cancel the schedule as > soon as possible. If the server is unable to cancel the scheduled RPC, for > example because it has already been executed, it should respond with an > rpc-error [RFC6241], in which the error-type is 'protocol', and the > error-tag is 'operation-failed'. > > > > > >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. > > > > > > Agreed. > We added the following to the introduction: > > The NETCONF time capability is intended for scheduling RPCs that should be > performed in the near future, allowing to coordinate simultaneous > configuration changes, or to specify an order of configuration updates. > Time-of-day-based policies and far-future scheduling, e.g., [Cond], are > outside the scope of this memo. > > [Cond] Watsen, K., "Conditional Enablement of > Configuration Nodes", draft-kwatsen-conditional-enablement-00 (expired), > 2013. > > > > > >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. > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
