1. The last paragraph of section 2 seems to be making an argument against supporting QCD. Would it be possible to add a counterpoint or to reword the paragraph? When I got to the end of the document, I found that section A.4 had the counterpoint I was looking for. Perhaps add a reference to section A.4 from the last paragraph of section 2. 2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is given as "(16-128 octets)". I suggest replacing this with "(variable)" so that the specific size requirement only appears in one place (section 5): "Tokens MUST be at least 16 octets long, and no more than 128 octets long, to facilitate storage and transmission." 3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange as follows" is vague. How soon is soon? How about: "SHOULD initiate an INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as follows". Or, omit "immediately" if that is not strictly necessary. 4. The final paragraph in section 4.3 mentions "key rollover" and "secret QCD keys" but these concepts have not been defined. It seems like this material would fit better in section 5 (Token Generation and Verification) where the cryptographic mechanism for QCD token generation is recommended. 5. Similarly, section 4.5 mentions "periodic rollover of the secret used for token generation" but token generation has not yet been covered. Perhaps a better solution than what I recommended in the prior comment would be to move all of section 5 (i.e. 5 through 5.3) before section 4. That way, token generation would be discussed before any mention of token secrets, keys or rollover in sections 4.1 through 4.5. 6. The first sentence on page 18 is an orphan. 7. In section 11, "contrinuted" should be "contributed". 8. Section A.1 says, "The disadvantage here, is that in IKEv2 an authentication exchange MUST have a piggy-backed Child SA set up." RFC 6023 specifies a childless IKE SA initiation so that sentence is not true for implementations that support RFC 6023.
Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694)
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
