Hi Deb, all, Focusing on this one:
> 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? For this one, I suggest to only record the implications and remove the discard language: OLD: 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. NEW: Section 2 includes provisions for modifying and deleting existing registration entries by registrants. Such requests may have operational implication on other entities that deploy that extension. Note that the registry does not include a history mechanism and there is no way to track deleted entries once they have been removed. This is important to record as one main motivation for creating this registry at the first place was: “RFCs 3735 and 5730 do not describe how extension development can be managed and coordinated. This has led to a situation in which server operators can develop different extensions to address similar needs, such as the provisioning of Value Added Tax (VAT) information. Clients then need to support multiple extensions that serve similar purposes, and interoperability suffers as a result. An IANA registry can be used to help manage and coordinate the development of protocol extensions. This document describes an IANA registry that will be used to coordinate the development of EPP extensions." Cheers, Med De : Deb Cooley <[email protected]> Envoyé : vendredi 5 juin 2026 19:00 À : Scott Hollenbeck <[email protected]>; [email protected]; BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected] Objet : 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? ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
