Mohamed Boucadair 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: ---------------------------------------------------------------------- Hi Valery, Thank you for the effort put into this specification. Also, thanks to Luis M. Contreras for the OPSDIR review (his first review for the opsdir team, BTW) and to Valery for engaging with Luis. Please find some comments below: # Guidance for those who will deploy >From the perspective of those who will deploy, I found appendix useful…but somehow late. Putting aside that appendix was not referenced in the document, having an applicability section early in the document with a guidance when to use this extension vs. RFC8784 would be my preferred approach. # Guards against too frequent changes For example, we do have CURRENT: If a fresh PPK is available to both peers at the time when an IKE SA is active, peers MAY use this fresh PPK without creating a new IKE SA from scratch. Is there some kind of timer used as a guard to protect against too frequent changes? # Preference policy CURRENT: However, if the responder supports both specifications and is configured to use PPKs, it has to choose one to use, thus it MUST return either USE_PPK_INT or USE_PPK notification in the response, but not both. Is there any provision for policy support here? Also, can we recommend a default value here? # Exemplify shortcomings and situations It would be helpful to exemplify the shortcomings mentioned in: CURRENT: Instead, it is supposed to be used in situations where the approach defined there has a significant shortcomings. Likewise, do we have examples of situations mentioned in the following excerpt? CURRENT: However, if the partners support both use PPKs in IKE_AUTH and this specification, then the latter MAY also be used in situations where using PPKs in IKE_AUTH suffices. BTW, what is meant by “partners” mentioned in that text? Do we mean initiator and responder? # Terminology anchor As I’m there, maybe consider adding the following (or similar) to Section 2: NEW: This document uses the terms defined in [RFC7296]. In particular, readers should be familiar with the terms "initiator" and "responder" as used in that document. Cheers, Med _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
