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.
Later, Mike
Sent from mobile, sorry for terse
On 26. Mar 2024, at 04:20, Randy Presuhn <randy_presuhn@xxxxxxxxxxxxxxxxxxx> wrote:
Hi -
On 2024-03-25 12:50 PM, S Moonesamy wrote:
Hi Mike,
At 11:49 AM 25-03-2024, Michael StJohns wrote:
Context for the IETF list. A set of IANA notes were included in RFC8447 that allowed IDs to be considered as satisfying "Specification Required" for the purpose of issuing code points in IANA registries. The IANA requires stable references for a Specification Required. However, to quote from the ID boilerplate, "It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
These two seem to be in conflict.
The "Specification Required" policy is defined in "Guidelines for Writing an IANA Considerations Section in RFCs" (BCP 26) as a formal public specification. The BCP also contains some information about the intent behind the policy. I'll quote some text from the BCP as it may easier for the occassional reader:
"Publication of an RFC is an ideal means of achieving this
requirement, but Specification Required is intended to also
cover the case of a document published outside of the RFC path,
including informal documentation."
There is also another policy which states "RFC Required" which is a bar higher in comparison with "Specification Required".
The "IANA Registry Updates for TLS and DTLS" (RFC 8447) is on the Standards Track. The RFC is about instructions for the designed experts and IANA. Section 12, for example, states that "It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc."
There is a conflict between BCP 26 and RFC 8447....
What is the conflict you see? The text you cited seems to me to present
no conflict. A posted Internet-Draft certainly seems to fit within
the realm of "a document published outside of the RFC path, including
informal documentation."
Randy
This is quite a long thread, so I apologize if I missed some of it.
While I don't personally oppose publishing RFCs to document existing practice, registering a codepoint is absolutely not a good reason to publish an RFC (unless of course the codepoint is in a registry that has an IANA policy of RFC Required, IETF Review, or Standards Action - which isn't the case any more for SSH Key Exchange Method Names [1]).
The registry that started this discussion (SSH Key Exchange Method Names) is set up as Expert Review, so there's no requirement to have a specification, and even if there were, that requirement is met by the existence of an Internet-Draft. This is a technique that we've used extensively in QUIC (for provisional registrations). I've personally registered values with their reference set to a draft, or set to a wiki page on GitHub, or with no reference at all. (Note that references to draft need to include the draft number, because that then makes it as immutable as an RFC.)
Taking a step back, the primary goal of an IANA registry is to avoid collisions, and that can be easily accomplished without any public specifications. I think it's good practice to document protocols and to place the reference in the registry next to the code point, but it's by no means a hard requirement. Additionally, the purpose of documenting protocols at the IETF is not only interoperability, it's intellectual property rights. Any Internet-Draft submitted to the datatracker is covered by RFC 8179, meaning that anyone can check for IPR on the datatracker and decide that they can implement this without having to worry too much about patents (I'm not a lawyer, talk to your lawyer before you do this, etc.).
If there is IETF consensus to publish something as RFC, then by all means do it. If there isn't, then don't. The registries don't come into it.
David (no hats)
On Tue, Mar 26, 2024 at 12:39 PM Michael StJohns <mstjohns@xxxxxxxxxxx> wrote:
