I would add one additional use case when a registry decides to implement and deploy an active working group draft, since that has historically been done and should be encouraged to gain implementation experience of the extension, and is often required to support the extension while the RFC process proceeds for business reasons. Based on the requirement to register the extension in RST 2.0 and the Next Round Registry Agreement, registries will either attempt to register them or clone them as proprietary extensions and attempt to register them. We need clear language in draft-ietf-regext-ext-registry-epp that disallows the registration of active IETF drafts in the EPP extension registry. This preceeds the XML registry registration language in draft-ietf-regext-ext-registry-epp. I personally don't believe the word "reserved" means "register" and should provide guidance to the DEs that the EPP extension registration requests of proprietary extensions cannot include IETF namespaces with or without the MUST. This language would support the registration requests of IETF drafts (active and abandoned), which I believe we'll want to address explicitly pending what happens with RST 2.0 (and the Next Round Registry Agreement ) that will drive the EPP extension registry registration demand.
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/2/25, 5:46 PM, "Hollenbeck, Scott" <[email protected] <mailto:[email protected]>> wrote: > -----Original Message----- > From: James Galvin <[email protected] <mailto:[email protected]>> > Sent: Sunday, November 2, 2025 4:16 PM > To: Hollenbeck, Scott <[email protected] > <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; Gould, James <[email protected] > <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: [EXTERNAL] Re: [regext] WG Last Call: draft-ietf-regext-ext-registry- > epp-00 (Ends 2025-10-27) > > 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. > > Speaking as a participant, > > I believe that “MUST” as first proposed by Andy is correct. > > I believe Jim Gould brings up a valid concern but I don’t think it’s an issue > that > needs attention, unless of course I’m misunderstanding something. Here’s why. > > We’re conflating ICANN RST 2.0 requirements with the IETF requirements for > the extension registry. As I understand the ICANN RST 2.0 requirements, the > extension needs to be registered. ICANN has no requirements on what that > registration looks like. > > In particular, the IETF should do its thing and if an extension makes it > through > IETF process to become an RFC, then it will get registered and it will use an > IETF > namespace. > > Separately, and independently, if an extension that is not an IETF product, > even > if it is derived from a potential IETF product, is needed then it simply > needs to > be added to the extension registry, published in some reasonable way, and of > course it would use any namespaces it needs that are not IETF namespaces. > > The point here is this working group DOES NOT care about ICANN requirements. > The extension registry is open for use. If a registry chooses to use an > extension > that is not an IETF work product, well, that’s their choice and the market > will > sort that out for them. > > ICANN requires of that registry that the extension be registered, which is > independent of whether or not it is an IETF work product. > > Unless of course I’ve completely missed something, which I’m sure someone > here will call out as needed. [SAH] Under most conditions, a requirement to ensure that the XML schema and namespace URIs are registered before registering the EPP extension isn't a problem. The DE can easily work with IANA to make that happen. IETF RFCs MUST use IETF namespaces. Proprietary extensions MUST use non-IETF namespaces. No problem. There's one situation that will prevent an extension from being registered if we require pre-registration of the URIs, and that's registration of an extension that's specified in an Internet-Draft. I'm not talking about drafts that are on track to become RFCs. Any attempt to register those outside the normal IETF processes should be rejected. I'm talking about drafts that a WG has decided to stop work on such that the draft won't progress to RFC status. We know for a fact that there are implementations of such drafts in the real world. Here's the likely sequence of events if we institute a requirement to ensure that the XML schema and namespace URIs are registered before registering the EPP extension: A working group has an active draft, with one or more implementations that use IETF namespace URIs (which is appropriate for a draft that's destined for RFC status). The working group decides to stop work on the draft for some reason. The draft is no longer updated, but it still uses IETF namespace URIs and there are still one or more implementations. One ore more of the implementers decides to try to register their implementation of the abandoned draft with IANA. The draft is the "specification required" for the EPP extension registry. IANA forwards the request to the EPP extension registry DEs, who do a wonderful, thorough review of the draft and the registration request. They find everything in order except for the fact that the references XML schema and namespace URIs haven't been registered. They report that to IANA, telling IANA that those values MUST be registered before the EPP extension registration request can be accepted. IANA sends a registration review request to the IETF XML Registry DE(s), who also do a wonderful, thorough review of the request. They note that the URIs are specified in an Internet-Draft that hasn't been through the IETF consensus process. RFC 3688 requires them to reject the registration request. They report their rejection to IANA. IANA returns to the EPP extension registry DE(s) and tells them that the URIs can't be registered because reference specification isn't an RFC. Now what? The EPP extension registry DE(s) are forced to reject the original registration request because the URIs can't be registered. Is this *really* the desired outcome? This may well drive those implementers to create local copies of the abandoned draft. Those copies might still reference the IETYF namespace URIs; they might get updated to use proprietary namespaces. If there are multiple implementations there's a likelihood that there will be multiple requests to register those local copies. What should the EPP extension registry DE(s) do when they're asked to approve multiple registrations of the exact same specification? There's already some text in the draft that discusses that possibility, but depending on how this discussion goes that text may need to be updated, too. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
