Thank you for that clarification. I haven't seen the option to modify or deactivate a registration in the 2+ years I've been an AD.
Deb On Wed, Jun 3, 2026 at 5:06 PM Amanda Baber <[email protected]> wrote: > Hi Deb, > > > About these two items: > > > > Section 2.2.3, para 1: How are requests to modify or deactivate > registrations > authenticated? Can anyone just masquerade as the POC make the request? > > > Section 4: Consider how an unauthenticated attacker could disrupt this > registry. Email addresses are super easy to spoof, what keeps this from > happening to either modify or deactivate an entry? > > IANA will cover this. We always send modification requests of any kind to > the original address, even if it appears to be the source, and ask them to > confirm the details. Sometimes the process includes additional steps, like > determining whether the original organization has been acquired by a new > one, or reaching out to the experts if there are unusual complications, > like an unclear chain of custody, but this is relatively routine for us > (mostly on account of the PEN registry, which typically sees something like > 30 modification requests per month). > > thanks, > Amanda > > > > > > > ------------------------------ > *From:* Deb Cooley via Datatracker <[email protected]> > *Sent:* Wednesday, June 3, 2026 11:09 AM > *To:* The IESG > *Cc:* [email protected]; [email protected]; > Gavin Brown; [email protected]; [email protected] > *Subject:* [Ext] [iesg] Deb Cooley's Discuss on > draft-ietf-regext-ext-registry-epp-07: (with DISCUSS and COMMENT) > > Deb Cooley has entered the following ballot position for > draft-ietf-regext-ext-registry-epp-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_rkuiOyA9HsFVAOXvZAT_3QrblEwsIjNDLZ8Q2JRQrKTjmP4iiSJduFu6QdYrYijmBg84CG8pW77oXi67JFkjK4$ > [ietf[.]org] > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-ext-registry-epp/__;!!PtGJab4!_rkuiOyA9HsFVAOXvZAT_3QrblEwsIjNDLZ8Q2JRQrKTjmP4iiSJduFu6QdYrYijmBg84CG8pW77oXi68yHsikY$ > [datatracker[.]ietf[.]org] > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > While I have divided my comments up into those I think are 'discuss > worthy' and > 'mere comments', I do believe all of my comments should be considered > carefully. The goal of this process specification is to have a clear and > concise set of instructions for those with submissions/changes to this > registry > and the DEs who will be doing the work to consider them. > > Many thanks to Tero Kivinen for their secdir review. I will also state > that I > agree with his points about: the status of the specification, the format > of the > references, the inclusion of '(or its future replacement)' - it should be > deleted. > > Process specifications are not protocol documents. There is no reason to > make > it PS when BCP works just fine - and especially when BCP was working group > consensus. (Even if there is one example process specification that is > standards track, the vast majority are not.) > > Section 2.1, second para, last sentence: Why aren't Internet Drafts are > not > acceptable? Do they not meet the 'permanent and readily available' > requirement? What if someone takes the contents of an I-D, posts it to a > site > that is considered 'permanent and readily available', can it be used then? > This > deviation from what is normally acceptable for 'specification required' > needs > to be explained. > > Section 2.1.1, para 2: Under what circumstances is it ok for a DE with a > COI > not defer? The SHOULD is currently naked, without rationale about when it > is > ok to ignore it. > > Section 2.2.3, para 1: How are requests to modify or deactivate > registrations > authenticated? Can anyone just masquerade as the POC make the request? > > Section 4: Consider how an unauthenticated attacker could disrupt this > registry. Email addresses are super easy to spoof, what keeps this from > happening to either modify or deactivate an entry? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2, general comment: Remove all of the RFC 8126 text (you don't > want to > have to update this specification when that RFC gets replaced and yes, > there is > a 8126bis already), it adds no value, just makes it harder to maintain this > specification. > > Section 2.2.1, Registrant name and email address: Wait, one can merely use > IETF, and the IESG's email address? How will this work? Don't we really > want > a person who knows more about the registration? For some other > registries, it > is acceptable to use a working group name and email address (Mediatypes, > for > example). > > Section 2.2.3, para 2 and 3: This is incomprehensible. Registrations that > were created w/ IETF and w/out IETF consensus can be approved by the > IESG? But > external registrations can just be summarily deactivated by the DEs? > > Section 5: I'm baffled by this section. This is a process specification, > why > are there operational considerations? Everything that exists in this > section > could be either moved elsewhere or removed. Para 1 belongs in Section 1, > para 2 > belongs in Section 2 with the rest of the DE instructions, para 3 can be > removed. > > >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
