Deb, regarding your question below:
[DC] Is this a rewrite? Or just an explanation for me? It was intended to be an explanation, but after multiple re-reads I think it’s easier to understand than the old text. I’ll rewrite the old text. I’ll submit an updated draft this morning. Scott From: Deb Cooley <[email protected]> Sent: Friday, June 5, 2026 1:00 PM To: Scott Hollenbeck <[email protected]>; [email protected]; BOUCADAIR Mohamed IMT/OLN <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [regext] Deb Cooley's Discuss on draft-ietf-regext-ext-registry-epp-07: (with DISCUSS and COMMENT) Med asked me to summarize my position after the telechat. In line w/ [DC] I will update my ballot when a new version of the draft is available. Deb On Wed, Jun 3, 2026 at 3:10 PM Scott Hollenbeck <[email protected] <mailto:[email protected]> > wrote: Thanks for the review, Deb. My responses can be found below. Scott > -----Original Message----- > From: Deb Cooley via Datatracker <[email protected] <mailto:[email protected]> > > Sent: Wednesday, June 3, 2026 2:10 PM > To: The IESG <[email protected] <mailto:[email protected]> > > Cc: [email protected] > <mailto:[email protected]> ; > [email protected] <mailto:[email protected]> ; > [email protected] <mailto:[email protected]> ; [email protected] > <mailto:[email protected]> > Subject: [regext] 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://www.ietf.org/about/groups/iesg/statements/handling- > ballot-positions/ > for more information about how to handle DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-ext-registry-epp/ > > > > ---------------------------------------------------------------------- > 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. [SAH] As I said in my response to Tero, the format of the references is consistent with current RFC Editor practice. I'll change them if directed by the IESG, but such instructions would be highly unusual given 9,000+ examples of RFCs that use the same format as this draft. [DC] while recognizing that is most certainly not true for all 10K RFCs, I'm fine with you leaving the same format. You should still ensure that you are consistent with the chosen format. A middle ground would be providing a short phrase the first time an RFC is referenced (Tero has done that for you). > 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.) [SAH] I imagine this will be part of the IESG discission on Thursday. I'll change the intended status to whatever the IESG requests. [DC] Again, I would prefer that this were destined to be a BCP, as the working group desires. While the registry itself enables interoperability, the process to construct the registry has no interoperability issues. > 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. [SAH] Section 2.2 of RFC 2026 says that " Internet-Drafts have no formal status, and are subject to change or removal at any time.". We know full well that exceptions can be made as described in 8126bis, but as 8126 bis says, "The working group or document that creates a "Specification Required" registry can declare that Internet-Drafts qualify for permanent registration within that registry. In the absence of such a declaration, however, Internet-Drafts are not eligible for permanent "Specification Required" registration.". Drafts are thus not normally acceptable for ''specification required". Accepting them is the deviation. This working group decided that it didn't want to accept them for the reasons described in 2026. [DC] In the Security Area, we view this differently. Hopefully 8126bis will clarify this for everyone. In the meanwhile, I'm gathering that allowing I-Ds as stable references is not typical. I suggest that you provide information on how to make it fair for all submissions. > 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. [SAH] that will be fixed as noted in my responses to others who made the same comment. [DC] ok > 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? [SAH] The intention is that only the original registrant or the IESG should be able to modify or deactivate registrations. Sections 2.2.3 and 2.2.4 of the draft address this from 2.2.3: "Registrations not created through IETF consensus can be removed or deactivated with the approval of the IESG, in consultation with or at the request of the Designated Experts. Registrations not created through IETF consensus can also be removed or deactivated by the original registrant, in consultation with the Designated Experts." >From 2.2.4: "Under normal circumstances, registry entries are only to be updated by the registrant. If the registrant becomes unavailable or otherwise unresponsive, a designated expert can submit a registration form to IANA to update the registrant information." [DC] IANA has clarified this for me (TYVM). They understood what my concern was. > 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? [SAH] This may be more of a question for IANA, since it relates to their normal processes for receiving and processing protocol registry management requests using email. [DC] IANA clarified their process (TYVM). > ---------------------------------------------------------------------- > 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. [SAH] Already noted by other IESG members. I've agreed to edit that text. [DC] good. > 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). [SAH] That's an IANA practice for registry entries created by RFC documents. This WG has stuck to that practice. [DC] ok > 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? [SAH] *Removal* of registrations created through IETF consensus MUST be approved by the IESG. Registrations not created through IETF consensus can be removed or deactivated with the approval of the IESG, or at the request of the original registrant, in consultation with or at the request of the Designated Experts. [DC] Is this a rewrite? Or just an explanation for me? > 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. [SAH] Calling Med... 😊 [DC] I'm not sure where this landed. Med?
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
