Re: [saag] SSH & Ntruprime

[Michael StJohns <[e-mail]>]

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.

Let me ask a few clarifying questions which you haven't as yet answered:

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?  What is the stable reference - a url to the text, 
pdf, html, xml version?  Where is this model documented?

2) If the ID changes (and hence there are later versions in the 
datatracker), is IANA required to track those changes?  Or was the ID 
that was current when the code point was assigned always and forever the 
document to which the assignment refers?

2a) Are you aware that for the existing ID refs in the IANA registry, 
the IANA makes its own copy?  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?

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?  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?  [[NB - we don't do this with 
RFCs because RFCs have that nice "obsoleted by" "updated by" set of tags 
that allows us to figure out if the codepoint behavior has changed in a 
controlled manner]]

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?  I ask because this 
seems different from the general early-assignment policy where we 
know/knew that the ID was planned to be ephemeral.

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?

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.  Doing anything else is lazy and will be fraught with 
misunderstandings.

Later, Mike