Re: [saag] SSH & Ntruprime
Amanda Baber <amanda.baber@iana.org> Thu, 28 March 2024 20:49 UTC
Return-Path: <amanda.baber@iana.org>
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 E94CAC16940A for <ietf@ietfa.amsl.com>; Thu, 28 Mar 2024 13:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, 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 NQWAupJbKClB for <ietf@ietfa.amsl.com>; Thu, 28 Mar 2024 13:49:23 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D76C14CE2B for <ietf@ietf.org>; Thu, 28 Mar 2024 13:49:23 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa2.lax.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 42SKnMoH027788 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <ietf@ietf.org>; Thu, 28 Mar 2024 20:49:22 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Thu, 28 Mar 2024 13:49:21 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.1258.028; Thu, 28 Mar 2024 13:49:21 -0700
From: Amanda Baber <amanda.baber@iana.org>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [saag] SSH & Ntruprime
Thread-Topic: [saag] SSH & Ntruprime
Thread-Index: AQHagVFon1E4p80axkSiONmJshIbaw==
Date: Thu, 28 Mar 2024 20:49:21 +0000
Message-ID: <ACA03432-1AE4-4ACB-B469-64AAF6F3FB52@iana.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.63.22070801
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3794478580_3625351324"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-28_17,2024-03-28_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZwEFlB1ApPGnvsvtN-sBYFELeJo>
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 20:49:28 -0000
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.) 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.) 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.) Amanda Baber IANA Operations Manager On 3/26/24, 8:02 PM, "ietf on behalf of John C Klensin" <ietf-bounces@ietf.org on behalf of john-ietf@jck.com> wrote: --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
- Re: [saag] SSH & Ntruprime Amanda Baber
- Re: [saag] SSH & Ntruprime Salz, Rich
- Re: [saag] SSH & Ntruprime Randy Presuhn
- Re: [saag] SSH & Ntruprime John C Klensin
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Randy Presuhn
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Randy Presuhn
- Re: [saag] SSH & Ntruprime John C Klensin
- Re: [saag] SSH & Ntruprime Carsten Bormann
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime John C Klensin
- Re: [saag] SSH & Ntruprime David Schinazi
- Re: [saag] SSH & Ntruprime Michael StJohns
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime Randy Presuhn
- Re: [saag] SSH & Ntruprime John C Klensin
- Re: [saag] SSH & Ntruprime S Moonesamy
- Re: [saag] SSH & Ntruprime John C Klensin
- Re: [saag] SSH & Ntruprime John Scudder
- Re: [saag] SSH & Ntruprime Eliot Lear
- Re: [saag] SSH & Ntruprime John Scudder
- Re: [saag] SSH & Ntruprime Keith Moore
- Registration of code points. Re: [saag] SSH & Ntr… Phillip Hallam-Baker