Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-add-ike-11: Yes
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-add-ike/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It really helps to achieve the goals of the ADD WG :-) (only regret is that the IPSECME WGLC was not formally extended to the ADD WG, a little more of cross-WG collaboration is always welcome even if authors are also very active in ADD). Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Patrick Mevzek, the DNS directorate reviewer, please consider this dns-dir review: https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir-telechat-mevzek-2023-04-04/ (and I have read Med's reply so all it good) and the previous https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc-mevzek-2023-03-16/ (and the authors/chairs have also replied) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) I second Paul Wouters' DISCUSS point #2 and Zahed's one (even if this may be the IPSECME WG usual process, it is not the IETF process). ## Section 1 In the discussion about private CA / address for the DNS resolver, one more sentence stating the obvious (when using a private CA then the client may use the digest info payload) would be welcome. Alternatively, moving this paragraph before the reference to the appendix will make it clearer the link with ENCDNS_DIGEST_INFO. ## Section 2 Should RFC 8499 be normative (note RFC 7296 is normative and used in the same way)? ## Section 3.2 What is the responder behaviour when receiving a CFG_REQUEST with "ADN Length" different from 0 ? Symmetrical case for the initiator when "Num Hash Algs" is not 1 in a CFG_SET. If the generic behaviour described in section 4 (`As a reminder, badly formatted attributes or unacceptable fields are handled as per Section 2.21 of [RFC7296].`), then why other fields (notably "R") have specific text ? The reminder of section 4 should rather be in section 3 (but this is a matter of taste). `Note that SHA2-256 is mandatory to implement` does this mean that SHA2-256 identifier *MUST* always be in the list or is it implicit and does not have to be in the list ? # NITS (non-blocking / cosmetic) ## Appendix A.1 No need to expand VPN as it is both well-known and used before without expansion ;) _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
