> -----Original Message----- > From: [email protected] <[email protected]> > Sent: Tuesday, October 14, 2025 10:51 AM > To: James Galvin <[email protected]>; draft-ietf-regext-ext-registry- > [email protected]; [email protected]; [email protected]; > [email protected]; Hollenbeck, Scott <[email protected]> > Subject: [EXTERNAL] Re: [regext] WG Last Call: > draft-ietf-regext-ext-registry- > epp-00 (Ends 2025-10-27) > > I support the publication. > > One nit in 2.2.3: > > IESG approval shall be imho used as term "IESG Approval" - reference to 4.10. > of RFC8126.
[SAH] OK, that makes sense. > ... 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. 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. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
