From: Jasdip Singh <[email protected]> Sent: Thursday, January 15, 2026 1:13 PM To: Hollenbeck, Scott <[email protected]>; REGEXT WG <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: I-D Action: draft-ietf-regext-ext-registry-epp-01.txt
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Scott, Not sure how useful this feedback would be but here it is. :) [SAH] Thanks, much appreciated! Are we comfortable having this document as Informational? (Knowing RFC 7451 is Informational.) Emulating the IETF XML Registry (RFC 3688), could it not be at least a BCP if not Standards Track. Key words “MUST”, “SHOULD”, etc help with clearer guidance, IMO. [SAH] I’m comfortable with it as-is, but a change is certainly possible if there’s some specific reason that the WG thinks it needs to change. Noting that the current EPP registry has the “TLDs” column for the domains side and it is required information, wonder if that's counter to "It is expected that this protocol will have additional uses beyond domain name registration.” from RFC 3750, and does it further connote that there can be no non-domain use cases for EPP? [SAH] I don’t think it does. Any non-domain-name-specific extension can populate that field with “N/A”. Adding text to make that clear could be helpful. Section 2.2.4 says: "In addition to entries that become "Inactive" due to a lack of implementation, entries for which a specification becomes consistently unavailable over time should be marked "Inactive" by the designated expert until the specification again becomes reliably available.” Should this criterion also be added to the “Status” definition in section 2.2.1 for the “Inactive” status part? AFAICT, "The "Inactive" status is used for extensions that are not implemented or are otherwise not being used.” doesn’t seem to connote specification unavailability. [SAH] I could add a forward reference from 2.2.1 to 2.2.4 and change the text in 2.2.1 to ensure that it’s consistent with 2.2.4. Thanks for the catch. There are few URIs in the document with the “http” scheme. E.g., "http://www.example.com/html/example-epp-ext.txt”. As a better practice, should they be changed to the “https” scheme? [SAH] Yes, they should be changed. I’ll fix that in -02. Otherwise, the document looks clear to me. Thanks, Jasdip From: Hollenbeck, Scott <[email protected]<mailto:[email protected]>> Date: Thursday, January 15, 2026 at 12:24 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [regext] Re: I-D Action: draft-ietf-regext-ext-registry-epp-01.txt > -----Original Message----- > From: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>> > Sent: Thursday, January 15, 2026 12:18 PM > To: [email protected]<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]> > Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-ext-registry-epp- > 01.txt > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > Internet-Draft draft-ietf-regext-ext-registry-epp-01.txt is now available. It > is a > work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. > > Title: Extension Registry for the Extensible Provisioning Protocol > Author: Scott Hollenbeck > Name: draft-ietf-regext-ext-registry-epp-01.txt > Pages: 11 > Dates: 2026-01-15 > > Abstract: > > The Extensible Provisioning Protocol (EPP) includes features to add > functionality by extending the protocol. It does not, however, > describe how those extensions are managed. This document describes a > procedure for the registration and management of extensions to EPP, > and it specifies a format for an IANA registry to record those > extensions. [SAH] Sorry, I'm impatient, so I'm going to be deliberately provocative by updating the draft based on the best information that I have in the hope of prompting discussion. This version of the draft captures the changes that were discussed during the WG last call process and proposed changes based on our interim meeting discussion from earlier this week. If I missed anything, or if you disagree with anything, please say so. It would also be helpful to note if you agree with these changes. Scott _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
