Re: [saag] SSH & Ntruprime

[Michael StJohns <[e-mail]>]

On 3/25/2024 12:52 PM, Orie Steele wrote:
> https://www.rfc-editor.org/rfc/rfc8126#section-4.6
>
> Makes it clear, the expert could decide to accept anything they are 
> directed to accept.
>
> In absence of guidance NOT to accept IDs, I would assert its at the 
> discretion of the expert, and can readily cite examples in the wild, 
> where specification required was satisfied with IDs, for example:
>
> https://www.iana.org/assignments/hpke/hpke.xhtml
> https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/02/
>
> If the draft above is ever updated to use a "generic kem combiner" the 
> code point for the -02 will need to be abandoned and a new one will 
> need to be assigned.
>
> Of course the same thing could happen if the reference were a github 
> readme at a specific commit.
>
> Probably no need to ask IANA, see this recent reply:
>
> https://mailarchive.ietf.org/arch/msg/kitten/nKpKSY9Lo9gL2rTju1xDqGFwbCo/
>
> All this aside, it's still my opinion that it's not a good thing to 
> encourage DE's to accept IDs, and if given the choice of specification 
> required and a link to a github repo (which can be deleted at any 
> time), and specification required with a link to an ID (which can be 
> deleted at any time)... I still prefer the external link, because it 
> does not create quality confusion regarding IETF documents... But I'll 
> concede my objection is more based on optics than deviation from process.
>
> OS

Hi Orie -

Let me bring your attention to the fact that if the assignment to this 
draft had been made around the time of RFC447, the link in the registry 
probably would now be wrong.  Sometime in recent history, we completely 
restructured the IETF website and the tools/datatracker sections and 
broke a lot of links - including I believe the ID links. For the 
purposes of datatracker, RFCDIFF and IPR related to ID's, this wasn't a 
problem, because the tools themselves were updated to point to the right 
places.

The IANA seems to have recognized this as they copy the current ID over 
to the IANA website. 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids 
numbers 60 and 61.  ID 60 references 
https://www.iana.org/go/draft-pismenny-tls-dtls-plaintext-sequence-number-01. 
However, looking at 
https://datatracker.ietf.org/doc/draft-pismenny-tls-dtls-plaintext-sequence-number/ 
There is now an 02 draft. *_Which is the proper reference for ID 60?_*

Has the IETF committed itself - through an actual public discussion - of 
making the IDs archival? Keeping them online - yes.  Keeping them at a 
fixed URL, I think not and I think RFC8447 was a mistake.  Referencing 
RFC8477 as precedent for Murray's question seems problematic.

I'd recommend revoking the notes on the existing registries that allow 
references to IDs. And, going forward, request the  IESG refrain from 
approving any further notes similar to those on RFC8447 until there's an 
actual consensus and a plan to support "archivalness" of the ID series 
(e.g. with a fixed URL and with a firm requirement that closes the path 
of updating the ID).

Later, Mike



>
>
> On Mon, Mar 25, 2024 at 9:26 AM Eric Rescorla <[e-mail]> wrote:
>
>
>
>     On Mon, Mar 25, 2024 at 9:22 AM Michael StJohns
>     <[e-mail]> wrote:
>
>         Trimmed.
>
>         On 3/25/2024 12:06 PM, Eric Rescorla wrote:
>>
>>
>>         On Mon, Mar 25, 2024 at 8:28 AM Orie Steele
>>         <[e-mail]>
>>         <mailto:[e-mail]> wrote:
>>
>>             > Internet-Drafts (often referred to simply as "drafts")
>>             have no formal status, and are subject to change or
>>             removal at any time; therefore they should not be cited
>>             or quoted in any formal document.
>>             we are the ones hosting their drafts.
>>
>>
>>         Yeah, this seems pretty speculative.
>>
>>         Fortunately, we have a natural experiment here, because RFC
>>         8446 explicitly allows the registration of TLS code points
>>         based on I-Ds, so in five years I guess we can see how that
>>         worked.
>>
>>         -Ekr
>>
>         Hi -
>
>         I just took a look at RFC8446 and I can't find support for
>         that claim.
>
>     My mistake, it's 8447. Muscle memory took over there.
>
>     See https://www.rfc-editor.org/rfc/rfc8447#section-7
>
>     -Ekr
>
>
>         The IANA considerations section refers to RFC8126 and only
>         "Specification Required" or "Standards Action" as the path to
>         registration.   Searching for "ID", "I-D", "internet draft"
>         and "Internet-Draft" doesn't get me anything.
>
>         AFAIK, "Specification Required" as defined in 8126 does not
>         include Internet Drafts, even under the heading of "informal
>         documentation" .  Maybe time to ask the IANA?
>
>         Later, Mike
>
>         _______________________________________________
>         saag mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/saag
>
>     _______________________________________________
>     saag mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/saag
>
>
>
> -- 
>
>
> ORIE STEELEChief Technology Officerwww.transmute.industries
>
> <https://transmute.industries>
>