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. 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]
