Thanks for the in-depth review; I expect we will hear more for sections after 2.16. I have incorporated all the editor comments and opened issues for many of the technical ones. Here is my list of ones that I have rejected; it does not include ones that Tero responded to and you agreed to drop. Please let me know if you have any issues with this list.
===== 1.4: "The processing of an INFORMATIONAL exchange is determined by its component payloads." Adding "The payloads are processed in strict left-to-right order" would make it deterministic, and is probably what people do today. [[ Response: New requirement; not OK. ]] ===== 1.4.1: In general the section is very wordy yet confusing: if each peer is responsible for deleting (=sending a delete payload for) its own incoming SAs, then why should we say that "one never sends delete payloads for the two sides of an SA in a single message". [[ Response: The wordiness helps implementers who were not here for the design of IKEv2. ]] ===== 1.4.1: the last paragraph springs a surprise by defining the behavior of IKE SA deletion while discussing an unlikely "messing up" of Child SAs. IKE SA deletion deserves its own subsection. [[ Response: it is optional behavior and makes sense. If you want a section on IKE SA deletion, you have to write it. I propose that it might be very late for doing that. ]] ===== 2: the last paragraph, beginning "The UDP payload" is out of place here. [[ Response: It is useful in the general sense of "IKE Protocol Details and Variations". It is described in more detail later. ]] ===== 2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange? We don't say we don't - although we do say that it would only be effective starting with IKE_AUTH. But I believe we should not accept it until both peers are fully authenticated. [[ Response: that would be a new prohibition. I don't see text in the current doc indicating this. ]] ===== 2.8: "An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages." A dummy message on an IPsec SA is way out of scope. Whether such messages even exist is a matter of local implementation. We certainly don't have IPsec-level keepalives. Overall, the last 3 paragraphs of 2.8 (starting "There are timing windows") are a mess: you have to read them several times before you realize that this is not normative text, rather it is several implementation alternatives. [[ Response: I found those paragraphs clear, but I might have missed something. Suggest rewording in a new ticket if you wish. ]] ===== 2.15: the value GenIKEHDR is confusing, because it is actually NOT including in the calculation. Is suggest to replace it with a clarifying sentence. [[ That is what we had earlier, and the WG reversed that and wanted it in the diagram. ]] --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
