On 22-10-2025 10:59 AM, Hollenbeck, Scott wrote:
-----Original Message-----
From: Andy Newton <[email protected]>
Sent: Tuesday, October 21, 2025 2:57 PM
To: Hollenbeck, Scott <[email protected]>;
[email protected]; draft-ietf-regext-ext-registry-
[email protected]; [email protected]
Subject: [EXTERNAL] Re: [regext] Re: 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.
On 10/21/25 14:23, Hollenbeck, Scott wrote:
Once there is an implementation of a particular version of an I-D,
does that mean a WG or the IETF are no longer free to change the
specification?
[SAH] Of course not, but you dodged *my* question. What are we trying to
accomplish? If our goal is transparency, I see more benefit in allowing the EPP
registration, not registering the squatted-on namespace URNs, and adding a
note to the EPP registry entry that the registered extension references
unregistered URNs than in rejecting the EPP registration.
So the IETF should sanction a process whereby the IETF's own BCP is being
violated? Then what is the point of having namespaces in EPP if they can be
violated? (which also brings up the issue that the DEs should be checking to
make sure new registrations aren't re-using URIs that are already registered)
Also, what happens if the IETF un-abandons the work?
The point I was attempting to make above is that if an implementation can
change within the WG process, it can change outside of it as well. That is, the
registration of the "abandoned" extension should have changed to use a non-
conflicted URI.
Also, the point of the IANA registry is interoperability. To that end, mistakes
made in the past should not continued to be made in the future.
[SAH] When dealing with a non-RFC specification, registration of both the EPP
extension and any XML schemas and/or namespaces is voluntary. There's no BCP
(are you referring to BCP 81?) violation if no one requests registration of the
values. So let's imagine that some submits a request to register an EPP
extension, and an expert notices that an XML namespace hasn't been registered.
If this draft says that the namespace MUST be registered in order to register
the EPP extension, and the requestor refuses to do so for some reason, the
extension registration request must be rejected and we lose information
describing the extension. If the draft says SHOULD be registered, we can still
register the EPP extension if the namespace isn't registered. I agree that it
isn't optimal, but I'd prefer to have the extension registered without the
namespace being registered as opposed to not registering the extension at all.
As I wrote above, we can always add a note in the EPP extension registry that
the namespace hasn't been registered for some reason.
We're talking about adding a normative requirement that will have an impact on
the DE review process. I'll repeat what I wrote yesterday about wanting more
input to better measure consensus.
If neither XML schemas or namespaces are required to be produced when
submitting a registration, then how does this work? (from 7451).
Extensions should be evaluated for architectural soundness using the
guidelines described in RFC 3735 [RFC3735], including the Security
Considerations section of that document. Expert evaluation should
explicitly include consideration of the privacy consequences of
proposed extensions, and, at a minimum, ensure that any privacy
considerations are fully documented in the relevant specification(s).
BTW, the BCP I was referencing was RFC 3688 / BCP 81.
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
