Thanks for the review, Med. I've added my reactions below.
Scott From: [email protected] <[email protected]> Sent: Tuesday, May 5, 2026 2:37 AM To: Registration Protocols Extensions <[email protected]>; [email protected] Subject: [regext] AD Review of draft-ietf-regext-ext-registry-epp Hi Scott, all, Thank you for the effort put into this update. When reviewing this document, I also reviewed the diff vs. RFC7451 and RFC3735. I have a set of comments for which I think a revised version is needed. My full review (including editorial suggestions, nits, etc.) can be found at: * pdf: <https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-iet f-regext-ext-registry-epp-06-rev%20Med.pdf> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf -regext-ext-registry-epp-06-rev%20Med.pdf * doc: <https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-iet f-regext-ext-registry-epp-06-rev%20Med.doc> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf -regext-ext-registry-epp-06-rev%20Med.doc I'm extracting the main comments fwiw: # Intended Status I suggest we change the status to Standard Track as this touches interop. [SAH] 7451 was Informational. The working group wanted to change the status of its successor to BCP because of the text that's here to describe the best practices for reviewing registration requests. I don't see an interoperability issue here. If you do, where is it? Additionally, placement on the Standards Track implies that there's a path for progression from Proposed Standard to Standard. RFC 6410 requires "measuring interoperability through widespread deployment of multiple implementations from different code bases" for that progression, but this draft doesn't describe anything that can be implemented in code or deployed. How would that work? # Add section with the main changes since RFC7451 The document already list some changes but some main changes are not reflected there (e.g., namespace check). [SAH] OK, I'll take another look at that text and add high-level descriptions of any missed major changes. # The document repeats some aspects that are in 8126. I suggest that we can avoid repeating or reinterpreting what is in these docs. I would shorten the text by having simple citations as appropriate. An example of interpretation is "Internet-Draft documents do not meet that requirement": the practice depends as function of registries. There are registries with specification required that accept I-Ds. I think that we just need to clearly record what is expected for EPP without making a generic statement on 8126. [SAH] The paragraph can be revised, but we still need to include text that identifies the set of acceptable specifications for this registry. How about this? OLD: The "Specification Required" policy requires review by a designated expert. Section 5 of [RFC8126] describes the role of designated experts and the function they perform. This policy also requires "a permanent and readily available public specification". RFC documents meet that requirement. Proprietary specifications may meet that requirement, depending on how they are archived and accessible. Internet-Draft documents do not meet that requirement. [RFC2026] notes that "Internet-Drafts have no formal status, and are subject to change or removal at any time". NEW: The "Specification Required" policy requires review by a designated expert. Section 5 of [RFC8126] describes the role of designated experts and the function they perform. 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. # Primary/Secondary CURRENT: The IESG should appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts, as described in Section 5.2 I see that the registry has primary/secondary indication. Is that something the we need to call out here? What are the expected primary/secondary roles? # What are the responsibilities of the chairs vs other DEs? CURRENT: The pool should have a single administrative chair who is appointed by the IESG. # I think that we need to make it clear that decisions must be motivated NEW: The decision MUST include justifications that motivated the decision. [SAH] In practice, our experts have operated with that administrative chair being the primary reviewer and the secondary reviewers being involved only if the primary reviewer is unavailable. It makes more sense to revise the description, perhaps like this: OLD: The IESG should appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts, as described in Section 5.2 of [RFC8126]. The pool should have a single administrative chair who is appointed by the IESG. NEW: 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. # Cover case of CoI for a DE at the end of Section 2.1 I suggest we add a text grabbed from a similar RFC for TLS registries: NEW: 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. [SAH] Agreed. # Should we say that the name should not overlap with already registered extensions? CURRENT: Name of Extension: A case-insensitive, ASCII text string that [SAH] Agreed. That text should include "does not overlap with an existing registered extension". # Mismatch with the registry CURRENT: For documents that are not RFCs, this will always be "Other". ## I see this not followed in the registry. For example: Balance Mapping for the Extensible Provisioning Protocol (EPP)Informational[][ <https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#VeriSi gn_Inc.> VeriSign_Inc.]AnyNoneActiveNone [SAH] Right, this needs to be fixed. That's why the document's IANA Considerations section includes a request to IANA to "Please change all non-RFC entries in the registry that have document status "Informational" to document status "Other"." ## We need to add a new IANA action to update all such entries to follow the guidance: [SAH] It's already there. # Consistency with the registry CURRENT: Registrant Name and Email Address: The name and email address of the person that is responsible for managing the registry entry. Should this be changed to "entity" as I see in the registry cases where the contact is not a person. [SAH] Yes, that should be changed. # Active/Inactive CURRENT: The "Inactive" status is used for extensions that are not implemented or are otherwise not being used. How this is determined? How this is maintained? Is this purely declarative? Should we recommend add a note where a disclosure was made? [SAH] The process is described in Section 2.2.4 of the draft. # Status Change CURRENT: If the Status value is "Inactive", text MUST be included to describe how and when this state was reached. I think this applies for any state transition change. The other transition is also interesting to track. Please update accordingly. [SAH] Agreed. # Expectation CURRENT: The required information MUST be formatted consistently using the Do we expect that formatting issues will lead to reject a request? Do we need to say so? [SAH] Formatting issues have not traditionally been a cause for rejection unless required information is missing. Perhaps this wording is better: "The required information MUST be provided using the" # Modify a registration: CAUTION! CURRENT: Registrations not created through IETF consensus can also be removed or deactivated by the original registrant, in consultation with the Designated Experts. How to make sure this change does impact uses by other entities than the registrant? There might be operational considerations out there. [SAH] I don't know if we can eliminate that impact. The registrant can't be held hostage by other implementors, some of whom may be unknown to the registrant and/or the expert(s). Those "unknown" implementors might be able to re-register an extension by producing their own specification, but that might not be possible due to copyright considerations. Deactivating an extension will have an impact on EPP clients, but should that override an EPP server operator's need to deactivate an extension? More thoughts below; I'm open to suggestions. # The WG may be concluded CURRENT: in consultation with the current working group mailing list focused on the development of EPP extensions. Please reword to avoid that dependency. Maybe: NEW: in consultation with the working group mailing list focused on the development of EPP extensions if such working group exists. [SAH] Agreed. # Make sure the guidance is applicable when 3735/regext mailing list/8179 are replaced I suggest to use the following formulations: * [RFC3735] (or its future replacement), * regext mailing list (or its successor) * [BCP79] instead of [RFC8179] [SAH] Agreed. # IANA considerations ## That section should be simplified as we do already have a registry. The section should be restricted to requested new IANA actions [SAH] Agreed. ## Missing actions We need at least two actions: (1) NEW: This document requests IANA to replace the reference of the EPP registry to the RFC number to be assigned to this document. (2) NEW: This document requests IANA to update "Document Status" of all non-RFC documents from "Informational" to "Other". [SAH] Agreed. # Missing Operational Considerations Section I suggest to cover at least the following: NEW: X. Operational Considerations The updates defined in this document are meant to enhance the guidance for reviewing EPP extensions (e.g., avoid squatting IETF namespace non IETF specification) and thus allows for better interoperability. Section 3 updates the content of "Document Status" to be compliant with the guidance in Section 2. That update does not impact the extension itself. No operational issues are induced by that update. Section 2 includes provisions for modifying and deleting existing registration entries by registrants. Such requests MUST NOT be granted if the requested action has operational implication on other entities that deploy that extension. # RFC7451 should be moved form normative to informative references Let me know if any clarification is needed. [SAH] This looks OK to me, except for maybe the "Section 2" paragraph. As noted above, the registrant and/or experts might not know of existing deployments. Plus, there's a situation where extensions are defined by a registry operator (an EPP server operator) and then implemented and deployed by both the registry operator and some number of registrars (EPP clients). Should it be impossible to deactivate a registered extension if a registrar complains? Most operators have existing methods of communicating such things, including (for example) processes defined in the ICANN and ccTLD community contexts. Maybe we could require all deactivation requests to include a description of attempts made by the requestor to minimize the impact of deactivation on potential impacted parties. At least that would give the DE(s) something to consider. I'll look at the complete list of comments and make other small changes as needed. Scott
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
