Hi Scott, Thank you for preparing this new version.
The version looks good to me. There are some nits that can be fixed after IETF LC: * s/RFCs 3735 [RFC3735] and 5730 RFC5730/RFCs 3735 [RFC3735] and 5730 [RFC5730] * The normative language is not appropriate here: s/action MUST be taken to comply/action must be taken to comply I will put the doc in the IETF LC right now. Cheers, Med De : Scott Hollenbeck <[email protected]> Envoyé : mardi 12 mai 2026 20:08 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; 'Registration Protocols Extensions' <[email protected]>; [email protected] Objet : RE: [regext] Re: AD Review of draft-ietf-regext-ext-registry-epp Med, I just submitted an updated draft. Please take a look when you can and let me know if I missed anything or if you disagree with any of the edits. https://datatracker.ietf.org/doc/draft-ietf-regext-ext-registry-epp/ Scott From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 6, 2026 3:29 PM To: Scott Hollenbeck <[email protected]<mailto:[email protected]>>; 'Registration Protocols Extensions' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [regext] Re: AD Review of draft-ietf-regext-ext-registry-epp Hi Scott, Thanks for the follow-up. Please see inline. Cheers, Med De : Scott Hollenbeck <[email protected]<mailto:[email protected]>> Envoyé : mercredi 6 mai 2026 19:12 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; 'Registration Protocols Extensions' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Objet : [regext] Re: AD Review of draft-ietf-regext-ext-registry-epp Thanks for the review, Med. I've added my reactions below. Scott From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Tuesday, May 5, 2026 2:37 AM To: Registration Protocols Extensions <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[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-ietf-regext-ext-registry-epp-06-rev%20Med.pdf * 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? [Med] I was approaching from a distinct perspective: (1) If this registry does not exist, several extensions covering the same functionality would be proposed and even requested to be part of a single implementation. With the information aggregated the registry we have a mechanism to flag those overlapping, and eventually use a registered extension that meet the need. This is the interop part I was referring to, especially that the registration includes a pointer for the spec governing an extensions. (2) If flagging functional duplication wasn't a concern, why do we bother at the first place with specification required and involve DEs in reviewing request (e.g., FCFS with admin info)? I may be mistaken, but the current policy was picked to help solving that duplication and rationalize that space. (3) A path that might be considered in the future is to merge this document if EPP base spec is 'bis' in the future. # 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. [Med] ACK # 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. [Med] This is great. Thanks. # 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. [Med] This is an enhancement. # 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. [Med] ACK # 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". [Med] Thanks. # 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[][VeriSign_Inc.<https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#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"." [Med] Thanks. ## 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. [Med] ACK # 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. [Med] Yeah, but I was looking more if there is a need to supply some kind of evidence of being "currently implemented and in use" (e.g., API, server). In other words, if a request includes "Active", does the DE ask about more information? # 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. [Med] ACK. # 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" [Med] This is better. Thanks. # 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. [Med] I think that we need at least to flag the implications in the document. Other approaches that might be considered: * Instead of removing the registration, consider adding a new column or a status "withdrawn" * Rather than deleting an entry immediately, include a date (e.g., 12 months after the request is received and granted) so that other implementers are prepared to manage the transition if they use it or whatever reason. # 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. [Med] ACK # 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. [Med] Thanks # 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. [Med] Thank you ## 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. [Med] ACK # 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. [Med] All these are good considerations in addition to the ones discussed above. I'll look at the complete list of comments and make other small changes as needed. [Med] Thank you Scott. Scott ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
