Thanks for the review, Ketan. My responses can be found below. Scott
> -----Original Message----- > From: Ketan Talaulikar via Datatracker <[email protected]> > Sent: Tuesday, June 2, 2026 1:09 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [regext] Ketan Talaulikar's Discuss on > draft-ietf-regext-ext-registry- > epp-07: (with DISCUSS and COMMENT) > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-regext-ext-registry-epp-07: 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-ext-registry-epp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to the author and the WG for this document. > > I have a discussion point that should be trivial to address. This has got to > do > with the part that details about the IANA registries, format of requests, DE > guidance, etc. should be under the IANA Considerations section per > RFC8126. A > trivial way to address this is to move all the content from under Section 2 > into the IANA Considerations. [SAH] The entire document is about creating and maintaining an IANA registry. It's a bit unusual in that regard, since that's often done in the IANA Considerations section of an RFC. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I also have a few comments to offer: > > 1) Doesn't the following belong under DE guidance? > > An English language version of the extension specification MUST be > referenced > from the registry, though non- English versions of the specification may also > be provided. Note that Section 2.1 of RFC 3735 [RFC3735] (or its future > replacement) provides specific guidelines for documenting EPP extensions. [SAH] Maybe. It needs to be somewhere. > 2) Regarding the following text: > > "For this registry, acceptable specifications include RFC documents and > proprietary specifications that meet the "permanent and readily available" > requirement described in Section 4.6 of [RFC8126]. Internet-Draft > documents are > not acceptable specifications for this registry." > > FYI - there is a 8126bis in the works that provides more flexibility in this > matter (it is still work-in-progress). Please check > https://www.ietf.org/archive/id/draft-ietf-ianabis-rfc8126bis- > 01.html#section-4.6.1.1 > I am not suggesting that anything be changed though; just sharing in case > this > was not already known. [SAH] Yes, that point is known, was considered, and was ultimately not what the WG wanted to do. > 3) Regarding the following text: > > "If the specification for an extension is an IETF Standards Track document, > no > review is required by the designated expert." > > Is that "document" or more specifically "RFC"? I ask because I-Ds are not > considered for allocation. [SAH] RFC, correct, but remember that Internet-Drafts have no formal status and aren't Standards Track documents. They may be *intended* for the Standards Track, but they're not there. That text needs to be fixed because as others have noted IANA's normal practice is to have the experts review the registration requests for Standards Track documents, too. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
