Hello Gavin Thanks for your prompt reply (and pruning the useless text in the data tracker email).
The proposed change for my DISCUSS point will indeed address it, i.e., I am clearing my DISCUSS ballot as soon as a revised I-D is submitted. About the ‘for’ attribute, while I understand the WG reasoning, then I wonder why not only using the regex (from customRRType) instead of the list in rrType... This unbalanced way of handling RRTYPE seems weird to my eyes. Anyway, even if I hesitated for a DISCUSS ballot on this point, it is actually just a comment, i.e., feel free to ignore (and again thanks for your explanation). Regards -éric From: Gavin Brown <gavin.br...@icann.org> Date: Tuesday, 17 December 2024 at 12:41 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-regext-epp-...@ietf.org <draft-ietf-regext-epp-...@ietf.org>, regext-cha...@ietf.org <regext-cha...@ietf.org>, regext@ietf.org <regext@ietf.org>, a...@hxr.us <a...@hxr.us>, anthony-i...@sts.io <anthony-i...@sts.io> Subject: Re: [Ext] Éric Vyncke's Discuss on draft-ietf-regext-epp-ttl-17: (with DISCUSS and COMMENT) Hi Éric, my responses are below. > On 16 Dec 2024, at 11:21, Éric Vyncke via Datatracker <nore...@ietf.org> > wrote: > > [snip] > > ## 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. Thanks for pointing this out, I would propose "EPP commands" and "EPP responses" instead. > ### 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. This choice arose during WG discussions. The list of DNS resource record types is not static, but the XML schema in this document is, so any list of RR types that is embedded into the schema will be obsolete shortly after the document is published as an RFC. To update the list of RR types requires a schema update, which in turn requires an RFC update, so the most likely outcome is that the list would never change once created. The "custom" attribute future-proofs the extension. Should a new DNS record type be defined that exists above a zone cut - DELEG is the specific thing that was being considered as an example - then it can be supported by this EPP extension without the need to update the XML schema. > ### Section 7 > > Strongly suggest to add the IANA registry URI as a reference to avoid any > ambiguity. Noted, I will make this change. > > ## 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). This will be fixed in the next version. Thanks, G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
