At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in
>section 2.23:
Fixed.
>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.
#122 is being fixed in the next draft, not the current draft. In it, I removed
the sentence you have a problem with.
>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 ..."
This has been in the document for quite a while. If it is important to you,
please open a new ticket for it and start a thread.
>4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}"
>before publication.
Yarrgh. So much for my regexps. Removed.
>5) Section 3.13.1, extraneous capitalization:
>
> o Selector Length - Specifies the length of this Traffic Selector
> Substructure including the header.
> ^
Fixed.
>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.
Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying
anything could lead readers to make assumptions that could end badly.
>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.
Exactly. We don't need to prohibit it, just cast aspersions on it.
>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?
Opened as Issue #128, on which I will start a new thread.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
