From ekr@rtfm.com Mon Mar 25 07:06:29 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 35C47C14F6BA for ; Mon, 25 Mar 2024 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 EnvOpUX9zeo9 for ; Mon, 25 Mar 2024 07:06:28 -0700 (PDT) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 A4E89C14F6B4 for ; Mon, 25 Mar 2024 07:06:28 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-60a15449303so42500907b3.0 for ; Mon, 25 Mar 2024 07:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1711375587; x=1711980387; 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=aM3Cna6gDD9I4hdLCDeg80XwuAL++JiUsxmUoPUorWI=; b=d29oiAE1g4HzAdu5Y0BN7pE3mZbZ9zCZ5BkTLa9AHkbuWVbC0mxXulZ9kVHdmMNXON NoC5KF2ndznjzwtwVaBzvI8Uo7bG4E7S9UP2w15CyqAt4CbPB9r60AazI/XGp9T6J10p pDlPSDiWc/yUg0rxxE+bja6LXrSBT/WAYciQqh/SiVfDbGc4SGtqrLC+FC5IRBp+yXWs rGLrQAi888uVcgYKY8Sy7btHeuJXkaeCYjxzy9NHe9g45q5ZEvKf8Ld7Y0vgKK0wUy80 a8emEEsjGkcnFGu53UsUhOMREVvybgKe8pKnu89dJz8F6qa2DMx7nwS3dRN8uVbWLwpz abMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711375587; x=1711980387; 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=aM3Cna6gDD9I4hdLCDeg80XwuAL++JiUsxmUoPUorWI=; b=p0vonKyxOnuulMAj09nqg2gSKVk9JxuKSKQOabtweDuVRZQ+YHR8Iqqc1vi0iv8z+S PAAK009fmpV8DyO2V0aJXI/r4kumnmuSn6aKvDnelxsJYqd7f/NP8j3rDNkRYZQgsaEY OixYugk3VGCm+NV4alQFO7lvsiDk6mX0tMMXQTN/B9MIoKI352KcwZ59WBpkz4Ch+I4x vfpFL50Hc+xi3tePFZQxEx1hYdT5HRLVNpTHzzUaPCFt2FDF2yL1uFB5syi5dPDLTQjw Duiz9uCgeUcyTCw0wdOT5NneVPEVPAEGGmeTDVlr3eTE5VjGVP7jjpR5EzyCmFOAlaI4 czXQ== X-Forwarded-Encrypted: i=1; AJvYcCV4pZpO2BNB+j437BPGgRifLzzAf8U7VbijDmKd0a+ptiYmL5gUguVdvqN3HOlhv69cihhOIqlAPWacXnxJ X-Gm-Message-State: AOJu0Yy0GmsCUtww5kBk8fAjLVQUqIbSI69NgO+wSbpJmpIRDoHgZHLD 3RjjP+jrQtdGCCVDqeVhxwlCmG+tM8WpdbhWqJ7UMhiz6cRwzcKfI2LFNcfBVinfF9Djhu6SKkV hx28lDP2aeHa24zqIPFHuH29PrBacmAoxLzwsig== X-Google-Smtp-Source: AGHT+IEbsi99jodW/rdYqXA/zkit6VhgQfwWNmYLbLJwgfRyKyR8wt8JncSY6751/a06rVKir2qvo+owIKaJjYyjDdM= X-Received: by 2002:a0d:f206:0:b0:60a:a77:6341 with SMTP id b6-20020a0df206000000b0060a0a776341mr4832581ywf.32.1711375587416; Mon, 25 Mar 2024 07:06:27 -0700 (PDT) MIME-Version: 1.0 References: <079A0AA3-FA02-440F-ABA0-6AF897570E86@sonic.net> <8caa2d4d-bc80-4fcf-b8bc-839052371730@lear.ch> <6c491f5c-92da-4fb3-a8b1-da1de27b36a6@lear.ch> In-Reply-To: <6c491f5c-92da-4fb3-a8b1-da1de27b36a6@lear.ch> From: Eric Rescorla Date: Mon, 25 Mar 2024 07:05:51 -0700 Message-ID: To: Eliot Lear Cc: Mark D Baushke , Paul Wouters , saag Content-Type: multipart/alternative; boundary="000000000000f7399606147caddb" 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: Mon, 25 Mar 2024 14:06:29 -0000 --000000000000f7399606147caddb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 25, 2024 at 6:53=E2=80=AFAM Eliot Lear wrote: > > On 25.03.2024 14:46, Eric Rescorla wrote: > > [Citation needed]. > > No. No citation needed because it happens during the development > process of a draft all the time, and you should know this because you've > written enough code to drafts. The point is, you don't know when a > draft is "finished". The benefit of an RFC or something similar is that > it is a signal that indeed the spec won't change. We make an exception > for early allocation for those drafts we know are going to become RFCs. > You seem to be confusing two cases: 1. The IETF is working on a draft that will eventually become an RFC. 2. Someone else wants to register a code point. In the former case, we don't register until the specification is stable, but in the latter case, the draft is used to document the code point for assignment. Obviously, you can't register code points against a specification which might, but once the code point is assigned, you can simply not change the draft, just as you don't change the RFC when published. If you're really concerned about this, however, we could simply register against a specific draft version, which is every bit as stable as an RFC. -Ekr > Eliot > > --000000000000f7399606147caddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Mar 25, 2024 at 6:53=E2=80=AFAM Eliot Lear <lear@lear.ch> wrote:

On 25.03.2024 14:46, Eric Rescorla wrote:
> [Citation needed].

No.=C2=A0 No citation needed because it happens during the development
process of a draft all the time, and you should know this because you'v= e
written enough code to drafts. The point is, you don't know when a
draft is "finished".=C2=A0 The benefit of an RFC or something sim= ilar is that
it is a signal that indeed the spec won't change.=C2=A0 We make an exce= ption
for early allocation for those drafts we know are going to become RFCs.=C2= =A0

You seem to be confusing two cases:

1. The IETF is working on a = draft that will eventually become an RFC.
2= . Someone else wants to register a code point.

In the former case, we don't r= egister until the specification is stable,
= but in the latter case, the draft is used to document the code point
<= div class=3D"gmail_quote">for assignment.

Obviously, you can't register c= ode points against a specification which
mi= ght, but once the code point is assigned, you can simply not change the
draft, just as you don't change the R= FC when published. If you're really
concerned about this, how= ever, we could simply register against a
specific draft version, = which is every bit as stable as an RFC.


=
-Ekr




Eliot

--000000000000f7399606147caddb--