Éric Vyncke has entered the following ballot position for draft-ietf-regext-epp-ttl-17: Discuss
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-regext-epp-ttl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-regext-epp-ttl-17 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points , some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Andy Newton for the shepherd's write-up including the WG consensus and the justification of the intended status. Other thanks to Anthony Somerset, the DNS directorate reviewer, and thanks for addressing his dns-dir review: https://datatracker.ietf.org/doc/review-ietf-regext-epp-ttl-17-dnsdir-lc-somerset-2024-11-11/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 1.2.1 The section (and possibly others) uses the terms `command frame` and `response frame`, which appear neither in RFC 5731 nor in RFC 5732. Require to use another term or to define it earlier in this I-D. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Section 1.2.1.2 It is mostly a DISCUSS point, but why using a "custom" attribute rather a IANA approved RRTYPE ? It adds complexity in the parsing for little value IMHO. ### Section 7 Strongly suggest to add the IANA registry URI as a reference to avoid any ambiguity. ## NITS (non-blocking / cosmetic) ### Section 2.1.1.1 Like written by Erik Kline, please use canonical IPv6 address format, i.e., s/2001:DB8::8:800:200C:417A/2001:db8::8:800:200c:417a/ (this issue appears at least twice in the document). _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
