I've finished my read through the draft. Note that I didn't give much scrutiny to the Config or EAP payloads, but I've read over everything else. A few more comments:
1) There are excessive spaces on the second lines of these list items in section 2.23: - If the server is behind a NAT, substitute the IP address in the TSr entries with the remote address of the IKE SA. ^ - If the client is behind a NAT, substitute the IP address in the TSi entries with the local address of the IKE SA. ^ 2) In section 3.3, this sentence: "If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122. It is also more strict than the "MAY" in section 3.3.3. Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft. 3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate. I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..." 4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication. 5) Section 3.13.1, extraneous capitalization: o Selector Length - Specifies the length of this Traffic Selector Substructure including the header. ^ 6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that. 7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message. Often, it is the only payload in the message." Out of curiosity, do we know of any cases where this payload is not the only payload in the message? It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted. I suppose since RFC 4306 allows it we don't have a lot of wiggle room here. 8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA? 9) Appendix D -- we need to fill this in. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer <yar...@checkpoint.com> To: "ipsec@ietf.org" <ipsec@ietf.org> Date: 12/10/2009 04:05 AM Subject: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) This is to begin a 4 week working group last call for draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718. Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. This is a large document, and arguably the most important document this WG is entrusted with. The LC period is longer than usual but will include vacation time for most of us. Nevertheless, please make an effort to review the entire document, or at least large portions of it. Feel free to post multiple partial reviews. In this particular case, we are starting the review with a few open issues . We will make an effort to close them during the WG LC period. As a reminder regarding the document’s scope (and our constraints while reviewing it), I will quote from my mail of Aug. 2008: General: The goal of the IKEv2 bis document is to clarify the protocol. The goal is not to extend it. Specifically: * The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 clarifications), but no other RFCs. * The document will add clarifications based on the community's deployment experience. * It is OK to correct minor technical errors and contradictions in the source documents. Any such corrections will be pointed out explicitly - preferably in an appendix (so that people using the old documents can scan it to discover problem areas). * The document will not add any "nice to have" extensions, no matter how much technical sense they make. Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document. The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06 Thanks, Yaron_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec