Re: [saag] SSH & Ntruprime

[Michael StJohns <[e-mail]>]

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 
>> <[e-mail]> 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
>>