Re: [saag] SSH & Ntruprime

John C Klensin <john-ietf@jck.com> Wed, 27 March 2024 03:02 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA845C14F61F for <ietf@ietfa.amsl.com>; Tue, 26 Mar 2024 20:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 4duE5pdSHmOf for <ietf@ietfa.amsl.com>; Tue, 26 Mar 2024 20:02:14 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F974C14F610 for <ietf@ietf.org>; Tue, 26 Mar 2024 20:02:13 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1rpJYI-000P6y-Md; Tue, 26 Mar 2024 23:02:10 -0400
Date: Tue, 26 Mar 2024 23:02:04 -0400
From: John C Klensin <john-ietf@jck.com>
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>, ietf@ietf.org
Subject: Re: [saag] SSH & Ntruprime
Message-ID: <4C707439EAF7D4378D0B5864@PSB>
In-Reply-To: <99bbd41d-1a75-4bd2-9a80-79dbcf3eebf8@alumni.stanford.edu>
References: <CABcZeBPWjXvLh06-DBO3Z0sfeb2hgzqzaSZ-J2-TZ7qesrSraA@mail.gmail.com> <CABcZeBOQYp49i_JjE7vdg6AjxwyvktW7LFTJ4Mh3jt0bmxxxDQ@mail.gmail.c om> <CAN8C-_+QUpU2bTeSFmLB7v1qLirTXtypR2U7D54JeEaeKfSp+Q@mail.gmail.c om> <CABcZeBNtE6PtEdmh-2rTC5y9U7yEL8JVNo1HMjZtOQw-DHjXQQ@mail.gmail.com> <88a1bb16-b0ef-49b3-a661-c343b4faa7a9@nthpermutation.com> <CABcZeBOo7e=jgrkMa4iXYy-x_2o6eZjTpEyezQiu7AKHk4ZhFQ@mail.gmail.com> <CAN8C-_JKbJLB6EU+8zUoeUgYVMkR4ErkSdpvuzr4LYoNcRKccA@mail.gmail.c om> <180b6873-d917-4a6f-9fa7-b174e0afae66@nthpermutation.com> <49C35FC4-17C2-48BD-86D4-5D18FD9CF860@akamai.com> <5f281744-d23e-4c54-aabd-741ba2952e45@nthpermutation.com> <6.2.5.6.2.20240325122757.133f0950@elandnews.com> <c140a11a-7930-471a-a3bc-5d4362e5889a@alumni.stanford.edu> <6.2.5.6.2.20240325134324.15278ce8@elandnews.com> <265a55d6-2a41-4119-81b3-ed7a29834dfa@alumni.stanford.edu> <7FCB15A13F0E3B6656CB151C@PSB> <e6130099-459f-496a-9176-b8ac2546b557@alumni.stanford.edu> <F1C6A81D8D19AD4A0E66FB43@PSB> <99bbd41d-1a75-4bd2-9a80-79dbcf3eebf8@alumni.stanford.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KQN4VMssosf0VALAFWh9sk8eRAY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2024 03:02:15 -0000


--On Tuesday, March 26, 2024 09:11 -0700 Randy Presuhn
<randy_presuhn@alumni.stanford.edu> wrote:

> Hi -
> 
> (top-posting)
> I think John and I are in close to violent agreement.
> 
> The devil being in the details, the question is whether
> any change is needed to current boilerplate / process /
> conventions (e.g. referencing specific versions of I-Ds,
> just as in referencing specific versions of standards or
> other documents when necessary) or whether this can be left
> to the good judgement of authors / editors / working groups.
> I'm inclined toward the latter, as what we have seems to
> already work well enough.

Randy,

Let me make an observation and suggestion that, I hope, will
bring us even closer to agreement.  Many years ago, IANA
considered it an important part of their role to evaluate the
details of registration requests.  Those evaluations included
the quality and availability of reference documentation.  If we
were still operating under those rules, I'd have no trouble
saying something like "good judgment of authors / editors /
working groups with the advice and consent of IANA" and moving
on.  In its most extreme form (in Jon Postel's lifetime), any
registration and any registry definition was a _request_ to IANA
and such requests could be held or even rejected until any IANA
concerns were satisfied.

As time has passed and organizational arrangements have evolved,
the IANA function has shifted more toward one in which the IETF
is expected to specify exactly how registries should be set up,
details of registration requirements, etc.  RFC 8126 reflects
some of that shift but it is nearly seven years old and recent
encounters have led me to believe that IANA is getting closer to
"just tell us what to do and, unless it is unclear or
impractical, we will do it".  That shift is not necessarily bad,
but it may mean that an author/ editor / WG with a focus on its
technical work (as it should be), little expertise in
registry-keeping and being sure that registrations are useful,
and, sometimes, in a hurry to just get done as work on a given
specification draws to a close, are not the best way to make
decisions about those details we used to assume IANA would take
care of.  Almost the same considerations would apply to
Designated Experts, etc.

So, given overextended ADs, I wonder if the IESG should ask for
volunteers for, and select, a small advisory committee to assist
IANA in evaluating registry applications, registration requests,
and marginal cases, focusing on technical issues including
document availability and possibly helping to oversee the
"expert review" process.  This would be very different from the
PTI directors -- no responsibility or involvement with domain
names, IP addresses, IANA or PTI administration, etc.-- just any
details or questions that might arise about protocol identifiers
and with responsibility for alerting the IETF community about
issues that seem to them to require broader review.

Would something like that make sense?

   john