Gorry Fairhurst has entered the following ballot position for draft-ietf-ipsecme-ikev2-qr-alt-08: 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-qr-alt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for producing this I-D for IKE. I really found it helpful to understand how this could work and to explain the new method. I have two comments that I really think ought to be considered before progression (but which I do not need to DISCUSS: (1) Please consider whether this ought to use RFC-2119 language, as /MAY/, it could be a protocol action (you or the responsbile AD will know best): "If this is inappropriate for the initiator, it may immediately delete this SA." (2) Appendix A contains a RFC 2119 keyword: /MAY/. I do not think this is normal to use keywords on appendices (you or the responsbile AD will know best), please consider using a lower case /may/ or simply explain it is an /alternative/. === I stumbled several times for non-technical reasons when reading, and therefore I have a few comments that I hope will allow others to also easilly read this useful I-D, for which I have tried to suggest new wording: Abstract: "way to get protection" - the word "get" seems to read strange to me, could you consider using "provide" or soemthing similar? "but protects the initial IKEv2 SA too", could be "but also protects the initial IKEv2 SA." Introduction: "At the time this extension was being developed, it was a consensus in the IPsecME WG that it is the IPsec traffic the one that mostly needs to be protected.", could be: "At the time this extension was being developed, the consensus in the IPsecME WG was to specify protection for the IPsec traffic." "However, in some situations it is desirable to have this protection for IKE SA", include /the/: "However, in some situations it is desirable to have this protection for the IKE SA". "An example of such situation is Group", include /a/ and /the/: "An example of such a situation is the Group" "In this protocol group policy and session keys are transferred from Group Controller/Key Server (GCKS) to Group Members (GM) immediately once an initial IKE SA is created. ", include /a/ and /the/: "In this protocol, group policy and session keys are immediately transferred from a Group Controller/Key Server (GCKS) to the Group Members (GM) once an initial IKE SA is created." Spec: "then the responder MUST return NO_PROPOSAL_CHOSEN notification.", include /a/? "then the responder MUST return a NO_PROPOSAL_CHOSEN notification." "If the negotiation was successful, the initiator includes one or more PPK_IDENTITY_KEY notification containing PPK identities the initiator believes are appropriate for the IKE SA being created, into the IKE_INTERMEDIATE request.", could be: "If the negotiation was successful, the initiator includes one or more PPK_IDENTITY_KEY notifications into the IKE_INTERMEDIATE request, containing the PPK identities that the initiator believes are appropriate for the IKE SA being created." Bullet 1&3:"If the responder is configured with one of the PPKs which IDs were sent by the initiator and this PPK matches the initiator's", seems hard to parse, maybe /with an ID that was sent/ ... or something similar? (the same comment applies to bullet 3). Bullet 2:"has some of proposed PPKs", include /the/: "has some of the proposed PPKs" "In case the responder", could be: "In the case that a responder" _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
