Re: [saag] SSH & Ntruprime

John C Klensin <john@jck.com> Thu, 28 March 2024 22:29 UTC

Return-Path: <john@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 AE6BCC1519B7 for <ietf@ietfa.amsl.com>; Thu, 28 Mar 2024 15:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 meBNGm4Eb_yL for <ietf@ietfa.amsl.com>; Thu, 28 Mar 2024 15:28:55 -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 1F646C15198D for <ietf@ietf.org>; Thu, 28 Mar 2024 15:28:54 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1rpyEt-000OWL-Hk; Thu, 28 Mar 2024 18:28:51 -0400
Date: Thu, 28 Mar 2024 18:28:45 -0400
From: John C Klensin <john@jck.com>
To: Amanda Baber <amanda.baber@iana.org>
cc: ietf@ietf.org
Subject: Re: [saag] SSH & Ntruprime
Message-ID: <A2C21DCBDCAB094E144891A7@PSB>
In-Reply-To: <ACA03432-1AE4-4ACB-B469-64AAF6F3FB52@iana.org>
References: <ACA03432-1AE4-4ACB-B469-64AAF6F3FB52@iana.org>
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@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/z7y2HrSI2dZNtE3XyE3tz05xcZ4>
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: Thu, 28 Mar 2024 22:29:00 -0000


--On Thursday, March 28, 2024 20:49 +0000 Amanda Baber
<amanda.baber@iana.org> wrote:

> Hi John, all,
> 
> About this:
> 
> "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."
> 
> Guidance would be welcome, but I should make a note about
> volume here: in 2023, IANA sent 348 review requests to
> IESG-designated experts and created 103 registries. (In 2005,
> we maintained something like 500 registries; today there are
> more than 3200.)

I was not contemplating bothering that group unless either IANA,
one of them, or an AD saw an issue.   I was thinking in terms of
a group whom you'd be more willing to consult (and more
responsive) than asking an AD or relying entirely on those whose
interests might be complicated... Not creating a new level of
bureaucracy.

Does that sound more plausible?

> Also, to the Specification Required point: my understanding is
> that this topic is being looked at for 8126bis. It should
> probably be noted as well that outside of TLS, when we do make
> this type of (infrequent) permanent allocation for an I-D, we
> typically do it for a set of registries that's managed by
> former ADs, so oversight may not be the issue so much as
> interpretation. (We're involved in the 8126bis work as well,
> but mostly in relation to terminology and processing issues.)

This is all fine, except that "looked at for 8126bis" has seemed
to be stuck for more than a year now.  So I no long assume that
we should wait for a draft to come out of that process.
 
> For what it's worth, RFC 8126 encourages authors who create
> Expert Review/Specification Required registries to include
> guidance for future experts. When we have other reasons to
> reach out to authors during our pre-IETF-meeting document
> reviews, we encourage this as well. (In the week before IETF
> 119, we read 450 IANA Considerations sections and reached out
> to 60 sets of authors with change requests.)

And that "encouragement" is another task I had in mind for this
group, directed to specs setting up new registries, i.e., having
some team in the IETF specifically tasked for reviewing such
guidance, including commenting when it is not present and
strengthening the encouragement rather than having many or most
area-designated reviewers glaze over when they reach the details
of IANA Considerations section.

best,
   john