On 28 May 2026, at 17:50, [email protected] wrote:
De : Scott Hollenbeck <[email protected]>
Envoyé : jeudi 28 mai 2026 18:34
From: Tero Kivinen via Datatracker <[email protected]>
Sent: Thursday, May 28, 2026 12:00 PM
Firstly this document has intended status of Standard Track, but it
does not provide any kind of protocol, it just describes the
processing rules for the IANA allocations for the EPP extensions
registry.
I completely agree with Tero here. Standards Track is not appropriate
for this document. More below:
I think BCP (or informational) should be better status for this
document than standard track.
[SAH] RFC 7451 was an Informational RFC. The working group decided to
change the intended status of this draft (its replacement), to BCP.
Med requested the change from BCP to Standards Track during AD
review. I'll defer to his judgment to address your suggestion.
[Med] I suggest to keep the current track for reasons already listed
in
https://mailarchive.ietf.org/arch/msg/regext/2EiYENIhQnkz_J9MDnKoy6zrQGI/.
In that message, Med writes:
(1) If this registry does not exist, several extensions covering
the same functionality would be proposed and even requested to be part
of a single implementation. With the information aggregated the
registry we have a mechanism to flag those overlapping, and eventually
use a registered extension that meet the need. This is the interop
part I was referring to, especially that the registration includes a
pointer for the spec governing an extensions.
The interop does not come out of the existence of the registry. It's not
like there are instructions in the protocol for accessing the registry
by implementations. The registry simply points to the documentation of
the extensions. More importantly, there is nothing in the establishment
of the registry that will move it along the Standards Track to full
Standard at any point. Creating a registry is a one-and-done operation
and not suitable for interoperability testing and progressive
development. It's clear from 2026 that this is either a BCP (because it
will have a more extensive IETF review) or it can simply be
Informational. Making this a Standards Track document makes the
distinction between documents meaningless. (Perhaps it already is, but
then why put the document in the position of being called "Proposed"?)
(2) If flagging functional duplication wasn't a concern, why do we
bother at the first place with specification required and involve DEs
in reviewing request (e.g., FCFS with admin info)? I may be mistaken,
but the current policy was picked to help solving that duplication and
rationalize that space.
And if it's a policy, it belongs as a BCP. Again, not Standards Track.
(3) A path that might be considered in the future is to merge this
document if EPP base spec is 'bis' in the future.
Which many protocol documents do as a matter of convenience. Having
non-standards-worthy information in a protocol document doesn't make the
information any more an independent standard than it makes the protocol
informational.
Please don't do this. Follow the initial recommendation of the working
group. Making this document standards track is completely arbitrary and
works to further weaken the idea of what makes something a standard.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
