Thanks for the review, Roman. I've added my responses below. Scott
> -----Original Message----- > From: Roman Danyliw via Datatracker <[email protected]> > Sent: Tuesday, June 2, 2026 2:57 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [regext] Roman Danyliw's Discuss on draft-ietf-regext-ext-registry- > epp-07: (with DISCUSS and COMMENT) > > Roman Danyliw 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: > ---------------------------------------------------------------------- > > ** Section 2.1.1 > The IESG should appoint a primary designated expert and a small > number of individuals (perhaps 3 - 5) to serve as backup designated > experts as described in Section 5.2 of [RFC8126]. The primary > designated expert is responsible for conducting all reviews requested > by IANA. The secondary designated experts are responsible for > conducting reviews as a consensus-based group if the primary > designated expert is unavailable. In cases where a registration > decision could be perceived as creating a conflict of interest for a > particular Designated Expert, that Expert SHOULD defer to the > judgment of the other Experts. The designated experts MUST use the > existing regext mailing list ([email protected]) or its successor for > public discussion of registration requests. > > This language above is a slight reinterpretation of Section 5.2, RFC8126. Is > that really necessary as the following are underspecified: [SAH] Correct. The original goal here (which predates 8126) was to provide specific guidance to the IESG for DE appointment. > -- What is a “consensus-based group” (e.g., rough consensus, majority, > unanimity) [SAH] The pool is small. A majority is probably appropriate. That can be specified. > -- When should a DE NOT recuse if there is a COI? [SAH] Probably never. That SHOULD can be changed to a MUST. > -- Is there a requirement being set on the IESG that it has to approved more > than one DE here (as the language reads, the “IESG should …”)? [SAH] Yes, the group wants more than one DE. We've been trying to "spread the wealth" in terms of DE education so that we aren't dependent on a single individual. In the past, I did almost all of the DE reviews myself. I retired from Verisign in March. Though I knew it was a few years away, I had a specific goal of minimizing the impact of my planned retirement when 7451 was written. The current pool of experts is younger, but it won't stay that way forever. We want there to be a diverse pool. > ** Section 2.1.1 > Should they decline to do so, perceived similarity SHOULD NOT be a > sufficient reason for rejection as long as all other requirements are > met. > > When is “perceived similarity” a sufficient reason to reject, as the guidance > says similarity is sometimes adequate justification (since MUST NOT is not > used)? [SAH] There's room here for human interpretation. That's another one of the reasons that we want a pool of experts, and reviews shared on the WG mailing list. We want to reject extensions that, for example, reuse XML schemas or namespaces that are found in an existing extension. An extension that makes minor changes to an XML schema may or may not be too similar to an existing extension, especially of the authors of the existing extension are willing to make changes to accommodate the proposed minor changes. > ** Section 2.2.3 > IESG Approval (Section 4.10 of [RFC8126]) is REQUIRED to remove or > deactivate registrations created through IETF consensus. > > What does it mean to “deactivate” a registration? [SAH] The status of an existing registry entry can be changed to "Inactive" as described in Section 2.2.1. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 2.1.1. Are these three statement providing unique normative > guidance? > The designated experts MUST use the > existing regext mailing list ([email protected]) or its successor for > public discussion of registration requests. > … > The results of the evaluation MUST be shared via email with the > registrant and the regext mailing list or its successor. > … > The designated experts MUST make an > explicit decision and that decision MUST be shared via email with the > registrant and the regext mailing list or its successor. [SAH] Not really. They're all intended to ensure that the experts share review results with the registrant and the mailing list in addition to the response the normally send to IANA. They can be combined. > ** Section 2.2.3 > On receipt of a registration request, IANA will initiate review by > the designated expert(s), who will evaluate the request using the > criteria in Section 2.1.1 in consultation with the current working > group mailing list focused on the development of EPP extensions if > such working group exists. > > Why is this text needed. It is restating what IANA already does for > “Specification Required”. [SAH] It was originally written to help registrants who might not understand the review process. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
