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]
