[Last-Call] Re: [regext] draft-ietf-regext-ext-registry-epp-07 ietf last call Secdir review

[[e-mail]]

Hi Pete,

I reiterate that interoperability is important for this specific case. This is why the document includes a discussion about the implication of withdrawing a registration.

The approach followed here is consistent with how this was handled for other similar efforts (e.g., RFC 9122). As a side note, I don't that we would have this discussion if the registry was created in RFC 4930 ;-)

Cheers,
Med

> -----Message d'origine-----
> De : Pete Resnick <[e-mail]>
> Envoyé : dimanche 31 mai 2026 21:57
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : Scott Hollenbeck <[e-mail]>; Tero Kivinen
> <[e-mail]>; [e-mail]; draft-ietf-regext-ext-registry-
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: [Last-Call] [regext] draft-ietf-regext-ext-registry-
> epp-07 ietf last call Secdir review
> 
> 
> On 28 May 2026, at 17:50, [e-mail] wrote:
> 
> >> De : Scott Hollenbeck <[e-mail]> Envoyé : jeudi 28
> mai
> >> 2026 18:34
> >>
> >>> From: Tero Kivinen via Datatracker <[e-mail]>
> >>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> mailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2F2EiYENIhQnkz_J9MDnKoy
> 6zrQGI%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf53f6d49
> 7237421e433a08debf4ecda3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C639158542339661184%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=%2BS%2FOVf7lAbalrWGFcA5e%2BtEXMXOdp0I8M
> xV1VV41CyU%3D&reserved=0.
> 
> 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
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.