> -----Original Message----- > From: Andy Newton <[email protected]> > Sent: Tuesday, June 2, 2026 11:56 AM > To: Scott Hollenbeck <[email protected]>; 'Mahesh > Jethanandani' <[email protected]>; 'The IESG' <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [iesg] Re: [regext] Mahesh Jethanandani's Discuss on draft-ietf- > regext-ext-registry-epp-07: (with DISCUSS and COMMENT) > > > > On 02-06-2026 6:37 AM, Scott Hollenbeck wrote: > >> Section 5, paragraph 1 > >>> Section 2 includes provisions for modifying and deleting existing > >>> registration entries by registrants. Such requests MUST NOT be > >>> granted if the requested action has operational implication on other > >>> entities that deploy that extension, assuming that those entities can > >>> be identified. This guidance can be overridden if the requested > >>> action MUST be taken to comply with actions that are beyond the > >>> control of the experts and/or IANA, e.g., to comply with legal > >>> actions. Note that the registry does not include a history mechanism > >>> and there is no way to track deleted entries once they have been > >>> removed. > >> > >> The second sentence in this paragraph makes the prohibition > conditional: > >> if affected parties cannot be identified, the constraint does not apply > >> and the removal could proceed despite potential operational impact. > >> If this is the intended policy, a brief rationale should be provided. > >> If not, the language should be tightened. > > > > [SAH] The operational implications can't be known if it's impossible to > identify operators. If a removal request is received, and the DEs make an > effort to identify operators to assess the operational implications of > removal, > and they fail to identify operators, the removal request should be honored. > The intention here is to avoid handcuffing IANA and the DEs who will be > required to review a future removal request. Would this change help? > > > > OLD > > Such requests MUST NOT be granted if the requested action has > operational implication on other entities that deploy that extension, > assuming that those entities can be identified. > > > > NEW. > > Such requests can have operational implications for entities that deploy > that extension. Designated Experts who review these requests MUST assess > the operational implications of removal, and they MUST NOT approve the > request if operational implications are identified. The request MAY be > granted if no operational implications are identified. > > Both the OLD and NEW need to be removed. They conflict with section 2.2.3. > The point of 2.2.3 is that it is the judgement of the IESG if the original > registrant is not making the request. The "no operational implications" > means that any excuse can be given to block the action. It would be best to > remove that entire paragraph.
[SAH] Andy, since that paragraph was added at Med's request during his AD review, can I ask that the two of you discuss this during the telechat? Let me know the outcome and I'll do whatever is decided. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
