[regext] Re: Deb Cooley's Discuss on draft-ietf-regext-ext-registry-epp-07: (with DISCUSS and COMMENT)

[Deb Cooley <[e-mail]>]

This is better.

I have two remaining questions:

1.  Status of the draft is still planning to be standards track?
2.  Section 5 para 3 points to the IANA section.  I'm not sure why there
would be operational impacts because of the way IANA works.  And in fact
that last sentence says that "No operational issues are induced by that
update".  One might save the paper/ink and just delete the paragraph.

Deb

On Mon, Jun 8, 2026 at 9:20 AM Scott Hollenbeck <[e-mail]>
wrote:

> 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 <[e-mail]>
> *Sent:* Friday, June 5, 2026 1:00 PM
> *To:* Scott Hollenbeck <[e-mail]>;
> [e-mail]; BOUCADAIR Mohamed IMT/OLN <
> [e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]>
> wrote:
>
> Thanks for the review, Deb. My responses can be found below.
>
> Scott
>
> > -----Original Message-----
> > From: Deb Cooley via Datatracker <[e-mail]>
> > Sent: Wednesday, June 3, 2026 2:10 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> ;
> > [e-mail]; [e-mail]
> > 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?
>