--On Tuesday, March 26, 2024 15:37 -0400 Michael StJohns <mstjohns@xxxxxxxxxxx> wrote: > On 3/26/2024 5:37 AM, Carsten Bormann wrote: >> Folks , Randy is right. >> >> If this discussion is intended to spark a rule change, please >> keep in mind that these rules weren't made for the >> security area, but for the whole of IANA. Please don't >> damage the parts you don't know about. > > For clarification, the rules with respect to "Specification > Required" were altered by 8447, for TLS and apply only to to > the registries covered by 8447. This rules change happened > without broad community review, and indeed without much review > within the security area. The notes within 8447 do not - to > my mind - reflect a community consensus to change the status > of Internet-Drafts globally, nor should RFC8447 be given > "precedent" status with respect to future and pending > documents. > > The rules for Specification Required have not changed and an > Internet Draft is not a stable reference for the purpose of > 8126 "Specification Required" section 4.6. for anything but > 8447 and it's unclear from the public record that the IESG of > the time had sufficient information for informed consent of > the RFC publication with those notes in it. It's possible > the private IESG archive will have more details than is > present in the data tracker for RFC8447. > > So I'm arguing against a rules change because I think we're > still at status quo with everything except the TLS registries > touched by RFC8447. > > If there is an intent to make ID's stable references, the > following things (IMHO) must be addressed: > > 1) The specification of a URL form that will be stable and a > commitment by the LLC and tools teams to maintain an archive > in that place in perpetuity. > > 2) The IANA agreeing that the archive is sufficiently stable > that they don't need to copy documents into their part of the > web tree as appears to be happening now with IDs. > > 3) A resolution of the whether the "stable reference" may > point to the entire ID sequence (e.g. via the datatracker) or > must it point to a specific stable document (e.g. a copy of > "draft-stjohns-foo-02.txt") and this needs to be consistently > applied. > > As of right now, there is at least one reference in the TLS > registries to a draft -01 version, but which has been replaced > by a draft -02 version in the datatracker. It's unclear to > me (and I would think a non-TLS participant or non-author) as > to which reference the code point applies and its a manual > step to research the datatracker link from the IANA registry > entry. I did not dig deeper here - it's possible the code > point was an early assignment of a pending RFC, as opposed to > RFC8447 assignment. As part of this resolution, > consideration might want to be made of: > > * whether or not an "only an ID" reference will be identified > separately from an early code point assignment. > * whether or not the assignment of a code point to a "not > ever an RFC > ID" locks the ID chain and prevents further submissions. > > 4) An update to RFC8126 section 4.7 to clarify that IDs are > permitted, and an update to the ID boilerplate reflecting > their new status. > > 5) (?) An update to the Trust Legal Provisions may be > necessary. E.g. Additional ID boiler plate so that an author > can restrict the referencing of an ID for the purposes of a > code point assignment? Similar to: > > This document may not be modified, and derivative works of > it may > not be created, and it may not be published except as an > Internet-Draft. > > 6) The LLC and IANA agreeing to all of the above and providing > funds if necessary to implement any necessary changes on the > part of the tools team and the IANA and RFC editor. For the > RFC editor, citing an ID for the purpose of citing the > document that owns a code point is different than our current > ID cites, but may be necessary for some future documents. > The consequences should be explored and described with respect > to a change of status for IDs. > > As I said, I don't necessarily disagree with what RFC8447 is > trying to do, but I think it hand waves a bit too much and > leaves a bit too much unclear for the future to clean up. > > Note that I do not consider that the above changes fall within > the remit of either the RSAB or the RSWG, and definitely not > within the remit of TLS. Mike, General agreement with all of your points, especially about the changes for RFC 8447 being specific to those particular registries. On quick reading, 8447 seems clear about that. Two additional observations: (7) In the introduction to Section 4, RFC 8126 makes it quite clear that one does not have to pick from among the list of ten "policies ... defined for common usage" in Section 4.1 - 4.10. That is reinforced in Section 4.11, which adds a requirement that "creation of new policies needs to be accompanied by reasonable justification". While it might be implied by some of the text, 8447 appears to not meet that justification requirement, nor to be clear on the issue (part of this thread) that its requirement should be treated as "additional guidelines for what kind of considerations should be taken into account by the review process" rather than as a change to "Specification Required". (8) Some broader issues about RFC 8126 than those specific to Specification Required may be appropriate to mention here. When developing draft-ietf-emailcore-rfc5321bis, the WG wrestled with a different problem than the documentation one, specifically the tension between getting as many keywords that were likely to appear on the Internet registered as possible (to provide some pointers and reduce the changes of name duplication) and the advantages of serious review in the IETF community in the hope of improving the quality of the underlying specifications, preventing or mitigating security issues, etc. The conclusion was to establish a registry with two distinct registration models (explicitly allowed by Section 4.12 of RFC 8126), one very lightweight and one more heavyweight. I am biased, but recommend Section 8.1.1 of draft-ietf-emailcore-rfc5321bis-27 as an example of how to specify a policy that combines, but varies from, those ten "common usage" policies of RFC 8126. My recollection is that we were told that a revision to RFC 8126 was in progress (or at least being contemplated) a year or more ago, one in which clarification along those lines (and possibly even a new recommended policy) might reasonably be included. In August 2023, draft-klensin-iana-consid-hybrid was posted in the hope of better establishing that sort of "hybrid" policy and/or stimulating the work on 8126bis. If people were interested, that I-D might easily be extended to include any necessary clarifications to the issues raised in your note (and the thread more generally) and then perhaps processed (I would welcome text or, better yet, a coauthor). In retrospect, perhaps that I-D should have been proposed for ALLDISPATCH for IETF 119 to at least raise the visibility of some of these issues. thanks, john
