Re: [saag] SSH & Ntruprime

[Eric Rescorla <[e-mail]>]

On Wed, Apr 10, 2024 at 9:59 AM Michael StJohns <[e-mail]>
wrote:

> On 4/10/2024 12:07 PM, Eric Rescorla wrote:
>
>
>
> I'm not proposing to push them away. I'm saying that that documentation
> does not require an RFC but rather that an ID is fine.
>
> -Ekr
>
>
> Hi Ekr -
>
> Saying an "ID is fine" does not make it so.
>
Sure. I'm just avoiding recapping my entire argument in every message.

Let me ask a few clarifying questions which you haven't as yet answered:
>
Well, as they weren't asked, this is hardly surprising.

1) If you're going to use the ID as a stable reference, do you use the
> entire name of the ID (including the version) or just a reference to the
> datatracker page?
>
The version.

  What is the stable reference - a url to the text, pdf, html, xml
> version?
>
I don't think this matters much. If these aren't equivalent, we have much
bigger problems.


> 2) If the ID changes (and hence there are later versions in the
> datatracker), is IANA required to track those changes?
>
No.


> Or was the ID that was current when the code point was assigned always and
> forever the document to which the assignment refers?
>
Yes, unless it is reassigned, which can be done with the same process.

2a) Are you aware that for the existing ID refs in the IANA registry, the
> IANA makes its own copy?
>
No, I wasn't, but I don't see that it matters.


> And that for at least one ID ref, the copy in the registry is at least one
> version behind the current datatracker info - e.g. already obsolete?
>
No, but I don't think this matters either, per my answer above.

3) If an ID - (draft-someone-mydraft-05) is abandoned and someone else
> picks it ups and runs with it under their own name
> (draft-someoneelse-samecontentasmydraft-00), is the IANA expected to track
> that?
>
No.

Or is the new author expected to make their own non-stable reference
> request for a new code point?  Or is there a policy that lets them
> overwrite the existing registration?
>
I would imagine the latter. I expect this to be an edge case that we could
resolve if and/when it became an issue.


> 4) Let's say that someone gets tired of all of the ID mess and decides to
> make it an RFC, is a new code point necessary?
>
Not from a process perspective. If the semantics have changed, this would
obviously be required.


5) Has the LLC committed to never moving the datatracker from the current
> URL?  And maintaining the current naming scheme? Or can this disappear like
> ftp.ietf.org and tools.ietf.org already have?
>
I don't see how this is relevant. The citation is not to the URL but to the
document, regardless of where it is hosted.
If it ever becomes the case that it's hard to find I-Ds by name, we have
much bigger problems.


> So if you want IDs to be stable references, write an RFC that addresses at
> least all of the above, and get community buy-in in the form of RFC BCP
> publication
>
As I noted in a previous reply to you, we already have RFC 8447, which has
the presumption of community consensus, at least for the TLS case.

You're of course free to object to extending that to other protocols or to
propose changing 8447, though I would be quite surprised if you got
consensus for the latter.

-Ekr