Having been reflecting on this further there is one element for which I would appreciate some additional discussion.
> We want to update the draft to explicitly disallow the registration of > Internet-Drafts or other "works in progress". Reference specifications should > be considered "final", though they can be updated using the change process > described in the draft. This concerns me because it seems to suggest that implementations of early versions of a final specification would be prevented from being able to “register” a specification. Is this intended (which I don’t think I could support) or am I misunderstanding something? Thanks, Jim On 4 Nov 2025, at 10:51, Hollenbeck, Scott wrote: > I had a chance to talk to both Andy and James while we're all in Montreal. > Here's what I think we all agreed on. If I'm wrong, please make corrections. > > We want to update the draft to explicitly disallow the registration of > Internet-Drafts or other "works in progress". Reference specifications should > be considered "final", though they can be updated using the change process > described in the draft. > > IETF URI namespaces MUST be reserved for IETF specifications. > > IETF XML namespace and schema URIs referenced in an IETF specification MUST > be registered in the IETF XML Registry defined by RFC 3688 before a request > to register an extension in the EPP extension registry will be accepted. > > Non-IETF XML namespace and schema URIs referenced in a non-IETF specification > SHOULD be registered in the IETF XML Registry defined by RFC 3688, but that's > not a requirement to register a non-IETF extension in the EPP extension > registry. > > Is this all correct? > > Scott > >> -----Original Message----- >> From: Gould, James <[email protected]> >> Sent: Monday, November 3, 2025 6:35 AM >> To: Hollenbeck, Scott <[email protected]>; [email protected] >> Cc: [email protected]; [email protected]; >> [email protected]; >> [email protected] >> Subject: Re: [EXTERNAL] Re: [regext] WG Last Call: >> draft-ietf-regext-ext-registry- >> epp-00 (Ends 2025-10-27) >> >> 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]
