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. # 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). # 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. # 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. # 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. # Should we say that the name should not overlap with already registered extensions? CURRENT: Name of Extension: A case-insensitive, ASCII text string that # 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[http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html][VeriSign_Inc.<https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#VeriSign_Inc.>]AnyNoneActiveNone ## We need to add a new IANA action to update all such entries to follow the guidance: # 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. # 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? # 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. # 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? # 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. # 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. # 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] # IANA considerations ## That section should be simplified as we do already have a registry. The section should be restricted to requested new IANA actions ## 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". # 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. Cheers, Med ____________________________________________________________________________________________________________ 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]
