Hi Scott. Thanks for your comments. My replies inline.
On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote: Comments on the draft, mostly editorial in nature: (1) There are still some blockquotes that start with excessive first-line indents, eg., the three quotes on page 5. Those are intentional. They quote from the RFC, so I copied them line by line. (2) Page 5, should add comma after "system" in "Reboot, depending on the system." Will be fixed in -04. (3) Page 5, should pluralize "implementation" in "IKEv2 implementation can detect." Will be fixed in -04. (4) Page 5, should remove "the" in "rules given in the section." Will be fixed in -04. (5) Page 6, correct "even has change" to "even has a chance." Will be fixed in -04. (6) Page 6, change comma to semicolon in "immediately, in those cases." Will be fixed in -04. (7) Page 6, suggest improving sentence beginning "Note, that" to read "Note that the IKEv2 specification specifically gives no guidance for the number of retries or the length of timeouts, as these do not affect interoperability." Will be fixed in -04. (8) Page 6, suggest changing "messages as hints that will shorten" to read "messages to shorten." Will be fixed in -04. (9) Global, need commas after "i.e." Will be fixed in -04. (10) Page 6, change "that kind of hints" to either "this kind of hint" or "these kinds of hints." Will be fixed in -04. (11) Page 7, pluralize first word in "Implementation that are not token takers." Will be fixed in -04. (12) Section 4.1, should we specify that the critical bit is set to 0? I think not, because that is true of any notify payload (13) Page 8, the last line is an orphan. Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN notification MUST NOT be taken" and then continues on the next page. (14) Section 4.2 says the payload "MUST follow . . . and precede . . ." In general I think the IKEv2 specs have tried to say SHOULD for ordering considerations; should we do so here? Agree that we shouldn't. RFC5996 specifically says that order doesn't matter. If nobody objects, I'll change it to a lower-case "should". (15) Section 4.3 says "SHOULD send a new ticket." I think we mean to say "QCD_TOKEN notification" instead of "ticket." No. That sentence is about session resumption (RFC 5723), where they do use "tickets". The second sentence talks about tokens: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. (16) Section 4.5, is it correct to denote the unprotected message as a "request" in the flow diagrams? I think we were careful in RFC 5996 to denote standalone messages as informational messages rather than informational requests. OK. I'll change it to "message" (17) Section 7, change "new IKE SA consume" to "new IKE SA to consume." OK. (18) Section 7, suggest changing "re-establishment should occur" to either "would occur" or "will occur." Agree, but I will solve it by moving the whole paragraph to the present tense: Session resumption, specified in [RFC5723], allows the setting up of a new IKE SA to consume less computing resources. This is particularly useful in the case of a remote access gateway that has many tunnels. A failure of such a gateway requires all these many remote access clients to establish an IKE SA either with the rebooted gateway or with a backup. This tunnel re-establishment occurs within a short period of time, creating a burden on the remote access gateway. Session resumption addresses this problem by having the clients store an encrypted derivative of the IKE SA for quick re- establishment. (19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add "an" before it or pluralize "gateway." Since the other bullet points are pluralized, I'll go with the former. Scott Moonen (smoo...@us.ibm.com<mailto:smoo...@us.ibm.com>) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen <graycol.gif>Internet-Drafts---01/10/2011 02:48:33 AM---A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> Date: 01/10/2011 02:48 AM Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt Sent by: ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org> ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-03.txt Pages : 23 Date : 2011-01-09 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonym...@ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt_______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec <ATT00001..txt>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
