Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract As the I-D is about authentication methods, I wonder whether `with multiple different credentials` is the right wording, should it rather be "different authentication methods" ? (of course with some text repetition). ## Section 3.1 `Regardless of whether the notification is received,` may be I am mis-reading this, but why would the responder send the notification if the initiator does not care anyway ? ## Section 3.2 While the readers may guess some details, but let's be clear in a proposed standard I-D: 1) `Notification Data field` does not appear in figure 4 2) role of C flag and its value 3) value of Protocol ID 4) saying that reserved field must be set to 0 by sender and ignored on the receiver ## Section 3.2.1 Let's be crisp and specify that the length is in octets. Is there a registry for authentication method ? or should this specification be updated for every new authentication method ? # NITS (non-blocking / cosmetic) ## Section 1 The last sentence of the 2nd paragraph is rather long and I think that "that" should be used in `the peer which supports wider range of`. ## Section 3.2.1 Missing closing parenthesis in the last paragraph. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
