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]
