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
