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. (2) Page 5, should add comma after "system" in "Reboot, depending on the system." (3) Page 5, should pluralize "implementation" in "IKEv2 implementation can detect." (4) Page 5, should remove "the" in "rules given in the section." (5) Page 6, correct "even has change" to "even has a chance." (6) Page 6, change comma to semicolon in "immediately, in those cases." (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." (8) Page 6, suggest changing "messages as hints that will shorten" to read "messages to shorten." (9) Global, need commas after "i.e." (10) Page 6, change "that kind of hints" to either "this kind of hint" or "these kinds of hints." (11) Page 7, pluralize first word in "Implementation that are not token takers." (12) Section 4.1, should we specify that the critical bit is set to 0? (13) Page 8, the last line is an orphan. (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? (15) Section 4.3 says "SHOULD send a new ticket." I think we mean to say "QCD_TOKEN notification" instead of "ticket." (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. (17) Section 7, change "new IKE SA consume" to "new IKE SA to consume." (18) Section 7, suggest changing "re-establishment should occur" to either "would occur" or "will occur." (19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add "an" before it or pluralize "gateway."
Scott Moonen ([email protected]) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: [email protected] To: [email protected] Cc: [email protected] Date: 01/10/2011 02:48 AM Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt Sent by: [email protected] 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://[email protected]/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
<<inline: graycol.gif>>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
