Re: [saag] SSH & Ntruprime

[Eric Rescorla <[e-mail]>]

On Mon, Mar 25, 2024 at 10:40 AM Michael StJohns <[e-mail]>
wrote:

> 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.
>
Well, that would obviously require IETF Consensus, so I suppose your first
step would be to write an ID.

And, going forward, request the  IESG  refrain from approving any further
> notes similar to those on RFC8447 until there's an actual consensus
>
I'm not sure on what basis you are saying that there's not an actual
consensus. RFC 8447 is the product of an IETF WG and went through the IETF
process, and so there is a presumption of consensus. In fact, it says so
right there in the boilerplate. I realize you object, but that doesn't mean
there wasn't rough consensus for RFC 8447.

-Ekr



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]>
>>> <[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 STEELE Chief Technology Officer www.transmute.industries
>
> <https://transmute.industries>
>
>
>