[regext] Re: WG Last Call: draft-ietf-regext-ext-registry-epp-00 (Ends 2025-10-27)

[James Galvin <[e-mail]>]

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.

Thanks,

Jim


On 24 Oct 2025, at 9:19, Hollenbeck, Scott wrote:

>> -----Original Message-----
>> From: Pawel Kowalik <[e-mail]>
>> Sent: Thursday, October 23, 2025 11:14 AM
>> To: Hollenbeck, Scott <[e-mail]>
>> Cc: [e-mail]; Gould, James <[e-mail]>;
>> draft-ietf-regext-ext- [e-mail]; [e-mail]
>> Subject: [EXTERNAL] Re: [regext] Re: WG Last Call:
>> draft-ietf-regext-ext-registry-
>> epp-00 (Ends 2025-10-27)
>>
>> I like the idea. Let's see what others say.
>
> [SAH] Here's a more specific proposal. In Section 2.1:
>
> OLD:
> URIs proposed in extensions (XML namespace and schema registration requests are commonly found in EPP extensions) should be evaluated for both syntactic and semantic correctness.  For example, IETF namespaces should be reserved for IETF specifications.
>
> NEW:
> URIs proposed in extensions (XML namespace and schema registration requests are commonly found in EPP extensions) should be evaluated for both syntactic and semantic correctness.  For example, IETF namespaces should be reserved for IETF specifications. URIs should be registered in the IETF XML Registry [RFC 3688] as appropriate.
>
> In Section 2.2.1, describe the complete set of possible document status values:
>
> OLD:
> The document status ("Informational", "Standards Track", "Other", etc.) of the specification document.  For documents that are not RFCs, this will always be "Other".
>
> NEW:
> The document status of the specification document.  For RFC documents, the possible set of values includes "Standards Track", "Informational", "Experimental", "Historic", and "BCP" as described in Sections 4 and 5 of RFC  2026 [RFC2026]. For documents that are not RFCs, this will always be "Other".
>
> Scott
> _______________________________________________
> regext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]