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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Andy Newton <[e-mail]>
> Sent: Wednesday, October 15, 2025 2:42 PM
> To: [e-mail] <kowalik=[e-mail]>; Hollenbeck, Scott
> <[e-mail]>; [e-mail]
> 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.
> 
> trimming the reply list
> 
> On 10/14/25 11:53, [e-mail] wrote:
> > Hi Scott,
> >
> > On 14.10.25 17:16, Hollenbeck, Scott wrote:
> >> [snip]
> >>
> >>> ... and a question
> >>>
> >>> 9.4. of RFC8126 makes a distinction between revocation and release.
> >>> Shall it be then also defined as "Records in this registry may be
> >>> revoked or released" or it is intended to have only revocation, so
> >>> the assignee cannot initiate the removal?
> >> [SAH] That section is about reclaiming previously assigned values for reuse.
> As I read that text, the concern is about protocol values that have meaning in
> some software implementation, and how a registry change can affect that
> meaning in future implementations. I don't think that's a risk here since this
> registry has a different purpose.
> >
> > PK> Yes, that's fine. I just wanted to highlight the risk people with interpret
> "revoke" as it is defined in rfc8126 when it is referred to in the same sentence,
> even if the context is not the same. One fix could be as I proposed above. Other
> could be to narrow down the reference to 4.10 instead of whole document.
> >
> >> There's nothing in the text that says who can (or can't) initiate removal,
> though. Maybe that should be fixed by adding "REVOKE" to the list of action
> requests found earlier in 2.2.3. It also begs the question of what REVOKE
> means. Does it mean remove completely, or change the registration state from
> "Active" to "Inactive"? I'd prefer to keep old entries listed so that they don't get
> lost. The text already describes how to change state from Inactive back to
> Active, so that's already covered.
> >
> > PK> I support and this was my feedback before to have "REVOKE" or
> "REMOVE" request mentioned in the text. I also support setting to "Inactive"
> instead of removal.
> 
> There should be an option to remove extensions that are inappropriate from the
> registry, such as those that may have references to docs that are unacceptable
> and those squatting on IETF namespaces. If we want to mark them inactive that
> is fine so long as the reference to them is removed.

[SAH] What's the benefit of removing the reference and retaining the registry entry? Not being able to see that inactive specification is bound to be an issue for someone, but 404s will probably be an issue, too. Is the best guidance for IANA to mark the entry inactive and remove the link for the reference specification?

Scott