From ekr@rtfm.com Wed Apr 10 10:31:09 2024 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483F0C14F5FA for ; Wed, 10 Apr 2024 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glpx3FzPHgjE for ; Wed, 10 Apr 2024 10:31:05 -0700 (PDT) Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEF8C14F5F4 for ; Wed, 10 Apr 2024 10:31:05 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-61587aa956eso65638777b3.1 for ; Wed, 10 Apr 2024 10:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1712770264; x=1713375064; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=biH4ZxenZFODIIyd4flnIRa5t/v5QrRJPuageg0P7jU=; b=UrbMzglcK/nbGQdFrC1BM05VlLqQaasPGFkXqfbLJJg8f1pS2Yfze1COtRUwo5d17D irEsG1YUpEKRRkl3EvjcrodTe0WolxZSCpZ8tJcVNrKk2pe7Uu83etEPV5cyk89dBOSS 4nTMvJ6NI4TEgMvSiUjKCpq+GJ6QJVPhzoRFOttL76YfOwPMuC/DtqS6PBT73/tj7UrZ X+IKVKbhrRnnpZaTfk45CgRChcxBS35gM7Mv0Y099AB1sMlMBE8NJC1v+F8aYYZE9UP5 oDiVMzYWPoPmpTNHkzewn5gXaHwT/UK2nCJgcq/Av+HrqSN2MjjeH80/41t3d8p0gVHD JH5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712770264; x=1713375064; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=biH4ZxenZFODIIyd4flnIRa5t/v5QrRJPuageg0P7jU=; b=XO+p0OuIZI1VMmoLLLDSGVOKxRxfdqNkkiAqrNiNb41XFXfSkHRwOj4j0jGu0b78Os ZcGfWMeqQYnjXzGF9mV3GEKVC1VFAZUIrVO6MnramjZnN4pcAHpKXGiXGF9zmJpSGm7w YW+shT3OHLGZBAGF55CgNwpslo4JPhmY4rh7hGklzRs5LjxY/FwZFzWjDjTm66vdFULD WOm5hhhIEXtjlrix+QExNiqNPQLwKMFxmrWiCrLoSkHeQRbhQcj3DPdAUo0N1kgqybcA +c8TOXaBY2pQkTe+QfAlLyl9YDRfGspWNcnO84IssL/kwjHavlkjp0MdA3/1HurQn35O N0rA== X-Gm-Message-State: AOJu0YzFkNuxR6vWCM9FJXk+7yyafMOsJsruPd0PNsBBOuhfXtd4HtPk pcPkEyrbic7Er4+7VH+PSvB/EiHBu0VRJEJl9TrFjPnpNPG6t3+D+Lw+aASONb1MuNS7gcXl/IQ 401dEGlzNzNFdnYMSaGqC+y2XGKlgta3aGpVOOELmsNfzgG5q X-Google-Smtp-Source: AGHT+IEVqQRqyJzSCo1DZB2FojsN0wvVMvLXQJMu6eQTeLRDZqOkr68F6ReZTCZHTRbXincNP4Sj0kcRb45wW8Aepn4= X-Received: by 2002:a81:4990:0:b0:611:278d:fb80 with SMTP id w138-20020a814990000000b00611278dfb80mr3876743ywa.8.1712770264178; Wed, 10 Apr 2024 10:31:04 -0700 (PDT) MIME-Version: 1.0 References: <05D73B77-ECFB-43E9-A2A8-00D46F63FC32@aiven.io> <20240405162821.1801419.qmail@cr.yp.to> <87o7ahzi8c.fsf@kaka.sjd.se> <9da5e8a6-b329-41cd-89c1-4423f6739341@nthpermutation.com> In-Reply-To: <9da5e8a6-b329-41cd-89c1-4423f6739341@nthpermutation.com> From: Eric Rescorla Date: Wed, 10 Apr 2024 10:30:27 -0700 Message-ID: To: Michael StJohns Cc: saag@ietf.org Content-Type: multipart/alternative; boundary="0000000000002dc3df0615c16735" Archived-At: Subject: Re: [saag] SSH & Ntruprime X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2024 17:31:09 -0000 --0000000000002dc3df0615c16735 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2024 at 9:59=E2=80=AFAM Michael StJohns 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 an= d > 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 on= e > 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 trac= k > 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 li= ke > 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 a= t > 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 --0000000000002dc3df0615c16735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 10, 2024 at 9:59=E2=80=AF= AM Michael StJohns <msj@nthper= mutation.com> wrote:
=20 =20 =20
On 4/10/2024 12:07 PM, Eric Rescorla wrote:
=20


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.=C2=A0

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 ver= sion.

=C2=A0 What is the stable reference - a url to the text, pdf, html, xml version?=C2=A0

I don't think this matters much. If these aren't equivalent= , we have much bigger problems.
=C2=A0

2) If the ID changes (and hence there are later versions in the datatracker), is IANA required to track those changes?=C2=A0

No.
=C2=A0

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 pr= ocess.

2a) Are you aware that for the existing ID refs in the IANA registry, the IANA makes its own copy?=C2=A0

<= div>No, I wasn't, but I don't see that it matters.
=C2=A0=

And tha= t 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 ab= ove.

=

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?=C2=A0

No.

Or is th= e new author expected to make their own non-stable reference request for a new code point?=C2=A0 Or is there = a policy that lets them overwrite the existing registration?

<= /blockquote>
I would imagine the latter. I expect this to be an edge ca= se that we could resolve if and/when it became an issue.
=C2= =A0

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?=C2=A0

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?=C2=A0 And maintaining the current naming scheme? Or can this disappear like = ftp.ietf.org and to= ols.ietf.org already have?

I don't s= ee 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 t= hat it's hard to find I-Ds by name, we have much bigger problems.
=C2=A0
=

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 presum= ption of community consensus, at least for the TLS case.

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

-Ekr
<= br>
=C2=A0
--0000000000002dc3df0615c16735--