Re: [saag] SSH & Ntruprime

[Michael StJohns <[e-mail]>]

On 4/10/2024 1:30 PM, Eric Rescorla wrote:
>
>
> 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.

https://mailarchive.ietf.org/arch/msg/ietf/X-YJliinZaP0Cc44w6P2zCvK8X8/

So pretend I was playing Jeopardy and didn't ask these in the form of a 
question.

>
>     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.
But what goes into a cite in another document that references this 
ID?     Is the IANA cite different?
>
>       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.

And again, what goes into a cite in another document that references 
this ID?

IANA doesn't do "Here are the search terms for the document for which we 
have issued a code point", it uses URLs.

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

And how do I tell the difference (by reading the IANA registry) between 
an early assignment ID which tracks the chain towards the publication of 
an RFC and this model?


>
>     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.

Again, this is not the expectation for our current "ID as reference 
pending an RFC" model.  I'm not actually aware that the codepoint 
assignment process allows you to update references except as part of the 
chain of documents during publication. Then we come to the question of 
"who" is allowed to update the reference and how does that get verified?


>
>     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.
You've taken the position that the ID ref refers to a specific version, 
however others may take the position that the ID ref refers to the 
latest ID in the chain.  Since neither of these are actually written 
down as policy for the IANA/IETF, both are perfectly valid or equally 
invalid.  Pick one - document it.
>
>     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.

Why not?  And let's go back to your answer to (2) - can the author of 
the new ID cause the assignment to now point to this new document?  
What's the process for doing so?  Who has to do the approvals?  What 
happens if the author of the abandoned ID then says "wait a minute - you 
stole my code point"?


>
>     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.
>
>
Can you show me the process documents for the IANA that would allow this 
to happen?  Or does this just get tracked as an "early assignment"?

>     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 <ftp://ftp.ietf.org> and
>     tools.ietf.org <http://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.

And that's pretty much the point of all of this.  Documents cite other 
documents.  If I can't find the reference, I can either a) search and 
try and find it, or b) treat the reference as dead.   A stable reference 
has a specific meaning and IDs do not qualify.

>
>     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.

Yeah - 8447 was an effective example of a submarine submission. I hope 
the IESG and IANA don't let something like that through again.  In any 
event, the IANA could actually require answers to the above questions be 
written down as part of their requirements for further registrations 
relative to 8447.

Thanks for answering my questions, but I note that they are your 
assertions and not documented elsewhere.

Later, Mike



>
> -Ekr
>