From blueroofmusic@gmail.com Mon Mar 25 13:07:48 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 CEE1AC14F6B0 for ; Mon, 25 Mar 2024 13:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.104 X-Spam-Level: X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.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 9zGnUJUPNbW5 for ; Mon, 25 Mar 2024 13:07:46 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 ACE6CC14F60B for ; Mon, 25 Mar 2024 13:07:46 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-47695273c19so2040433137.3 for ; Mon, 25 Mar 2024 13:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711397265; x=1712002065; 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=oQoB/D2CtXS9YMCZTfw9naDMABREdo+reWroI0sl4p0=; b=Wo14EbcSCPi8AfqTIJUfk4u61gaNzloYCspiJcGwsRH956xglT1K/b9z65kVO8kAB0 /9SbS4iKrWO56nxefAbs5KIo9lcP08nMhQk1cAoPRbMO5hlpC0gdSkgURU353yx4VSYr 0/SGZXLcjWptyaOOJFM7Wb/DkC2UZE9wZK3dQjFx+0eT7LyGqZ2ZXB3Ijk7OWbh0nVEu FQmDjEFGPMLvyFZVIGN4ok2lpqvujQ4Sy3kGlG9Ta0+zXn0qP4mW8pAmQibTQ3CB5HG4 LMyn4i/JSdZ71Id0VwaoArScKsgQY76+w1zms9iaX+IaHf4c1E2ydJnjkpb51kGjGmWB R1DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711397265; x=1712002065; 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=oQoB/D2CtXS9YMCZTfw9naDMABREdo+reWroI0sl4p0=; b=E8EDpQ8htywp7xKp4MOK5ijOdO7TGTtJUHb9wV/6q0NfD3BgOF6viUsT9YYksU2n2q aZgpEwO8M4OWz54lqJYS5ahemGE0wuHet3G6S9aeqerdKKqGKgDD2L52y5ccoOd0Atp4 eALKpfw6xCnxQGnfzSqE7l8wYkUTTaU2QLGCSmKmSENZXLE1VCUAg9i67UEiHddNdBJK iCi988I/VnvxAmJN6mmyDF8lpEC0dmlZzuW5+B2TqaP/aJa0JWeKqjjLHCP+4/3uela+ ih2Be4hy9ndiU93U/nEKLkXjxxMM/2elTqOp5uvmxVfzbZspf4pdQSW78OL4BiJXf435 QAiA== X-Forwarded-Encrypted: i=1; AJvYcCWgNUZpOQuYSnFu+/CS+Cwfrc9ONmVMkBkupQ0jpcmYyqqJ46Au54eJD9ERderTvwTyjavpFccwlEYjmNyo X-Gm-Message-State: AOJu0Yx0+YN5ZxGsM2vrtadWClBQTLRy1MfzAurqsdXNxM4oJVyYgTvX QwXCMpVDXUCsZ4gePnR59bIuWIfIewkkvsF4Jgh8dolO6sP+VPvhUBFIQwwI26XwDKdMoOaZMDv rTVidwkE7TT5D6yojXsI+69hMu+k= X-Google-Smtp-Source: AGHT+IGlR13oKndqsjsSLPMIB8kT0JmSyeh9yVOYzPHuC9CSsYJDe2aKq+UNl41kmdMyuvUt00O03xfWpmRBYOtfUG4= X-Received: by 2002:a05:6122:2194:b0:4d4:126b:2c8 with SMTP id j20-20020a056122219400b004d4126b02c8mr6158965vkd.9.1711397264470; Mon, 25 Mar 2024 13:07:44 -0700 (PDT) MIME-Version: 1.0 References: <6c491f5c-92da-4fb3-a8b1-da1de27b36a6@lear.ch> <64e81f68-5169-4469-b5a0-2851da912091@lear.ch> <7b4d38b8-b4c1-412b-8287-bd44d0c512a3@lear.ch> <88a1bb16-b0ef-49b3-a661-c343b4faa7a9@nthpermutation.com> <180b6873-d917-4a6f-9fa7-b174e0afae66@nthpermutation.com> <49C35FC4-17C2-48BD-86D4-5D18FD9CF860@akamai.com> <2D885F8D-0B31-4338-9D82-AC9AAC23CD51@akamai.com> <872c2d08-14a7-4147-8479-6407c09dc8f4@nthpermutation.com> In-Reply-To: <872c2d08-14a7-4147-8479-6407c09dc8f4@nthpermutation.com> From: Ira McDonald Date: Mon, 25 Mar 2024 16:07:24 -0400 Message-ID: To: Michael StJohns , Ira McDonald Cc: "Salz, Rich" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="00000000000004ba2b061481ba7d" 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 20:07:48 -0000 --00000000000004ba2b061481ba7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This thread took an interesting 45 minutes to read thoughtfully. My two cents - Mike St Johns is right that, at a minimum, we should fix the I-D boilerplate. And documents that don't have a *completely* stable public URI have no business being used to satisfy "Specification Required". Cheers, - Ira On Mon, Mar 25, 2024 at 3:33=E2=80=AFPM Michael StJohns wrote: > On 3/25/2024 3:01 PM, Salz, Rich wrote: > > Has the IETF committed itself - through an actual public discussion - of > making the IDs archival? Keeping them online - yes. Keeping them at a > fixed URL, I think not and I think RFC8447 was a mistake. Referencing > RFC8477 as precedent for Murray's question seems problematic. > > If you really want to know, perhaps ask tools-discuss email? Or search > the email archives. > > Someone sent me a pointer off-line. Thanks to that person, who wishes to > remain anonymous :) The IESG issued a statement in October 2012 [1] after > starting a discussion the month before [2]. The discussion was, shall we > say, =E2=80=9Cextensive.=E2=80=9D > > [1] > https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-removal= -of-an-internet-draft-from-the-ietf-web-site-20121025/ > > [2] > https://mailarchive.ietf.org/arch/msg/ietf/Jea_pkJrsgI1dUWvaNdROPY5KCs/ > > > > Yup - I remember this. However, this inapposite (yes, been reading too > many court filings) to the question of "stable reference" which lies at t= he > heart of the RFC 8126 requirement for "Specification Required". > > The intention behind "permanent and readily available" is that a > document can reasonably be expected to be findable and retrievable > long after IANA assignment of the requested value. Publication of an > RFC is an ideal means of achieving this requirement, but > Specification Required is intended to also cover the case of a > document published outside of the RFC path, including informal > documentation. > > The language of the statement at [2] does not provide for a stable > reference, and allows for the removal of various IDs to a private archive > under certain circumstances. [2] DOES end the practice of removing expir= ed > drafts from the public archive and that was about it. It didn't say > anything about keeping the public archive at a fixed location. And, > indeed, the public FTP archive of IDs is some what recently deceased. > There's a wide gulf between the meaning of "Don't delete" and "Archive". > > What's the proper cite for a stable ID? The IANA apparently copies the > current version over to their own files and references that in the > registry, but the rest of us generally cite the datatracker page, or > occasionally one of the archived .txt, .xml, .html or .pdf versions of th= e > document as appropriate. Or in the past, the tools page which was at tim= es > much more useful that then the datatracker. > > I understand what 8447 wanted to accomplish, I just don't think it went > about it the right way. I don't think it should be a precedent for futur= e > documents without actually writing down the backing requirements and maki= ng > sure they're institutionalized across the IETF organizations. > > Later, Mike > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --00000000000004ba2b061481ba7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This thread took an inte= resting 45 minutes to read thoughtfully.

My two ce= nts - Mike St Johns is right that, at a minimum, we should fix the I-D boil= erplate.
And documents that don't have a *completely* stable = public URI have no business being
used to satisfy "Specifica= tion Required".

Cheers,
- Ira
=

On Mon, Mar 25, 2024 at 3:33=E2=80=AFPM Michael S= tJohns <msj@nthpermutation.com= > wrote:
= =20 =20 =20
On 3/25/2024 3:01 PM, Salz, Rich wrote:
=20 =20 =20

Has the IETF committed itself - through an actual public discussion - of making the IDs archival? Keeping them online - yes.=C2=A0 Keeping them at a fixe= d URL, I think not and I think RFC8447 was a mistake.=C2=A0 Referencing RFC8477 as precedent for Murray's question seems problematic.

If you really want to know, perhaps ask tools-discuss email?=C2=A0 Or search the email archives.

Someone sent me a pointer off-line. Thanks to that person, who wishes to remain anonymous :) The IESG issued a statement in October 2012 [1] after starting a discussion the month before [2].=C2=A0 The discussion was, shall we say, =E2=80=9Cextensive.=E2=80=9D

[1] https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-removal-o= f-an-internet-draft-from-the-ietf-web-site-20121025/

[2] https://mailarchive.ietf.org/arch/msg/ietf/Jea_pkJrsgI1dUWvaNdROPY5KCs/=

=C2=A0

Yup - I remember this.=C2=A0 However, this inapposite (yes, been reading too many court filings) to the question of "stable reference" which lies at the heart of the RFC 8126 requirement f= or "Specification Required".

The intention behind "permanent and readily available&quo=
t; is that a
   document can reasonably be expected to be findable and retrievable
   long after IANA assignment of the requested value.  Publication of an
   RFC is an ideal means of achieving this requirement, but
   Specification Required is intended to also cover the case of a
   document published outside of the RFC path, including informal
   documentation.

The language of the statement at [2] does not provide for a stable reference, and allows for the removal of various IDs to a private archive under certain circumstances.=C2=A0 [2] DOES end the practice of removing expired drafts from the public archive and that was about it.=C2=A0 It didn't say anything about keeping the public archive at a fixed location.=C2=A0 And, indeed, the public FTP archive of IDs is some what recently deceased.=C2=A0 There's a wi= de gulf between the meaning of=C2=A0 "Don't delete" and &q= uot;Archive".

What's the proper cite for a stable ID?=C2=A0 The IANA apparentl= y copies the current version over to their own files and references that in the registry, but the rest of us generally cite the datatracker page, or occasionally one of the archived .txt, .xml, .html or .pdf versions of the document as appropriate.=C2=A0 Or in th= e past, the tools page which was at times much more useful that then the datatracker.

I understand what 8447 wanted to accomplish, I just don't think it went about it the right way.=C2=A0 I don't think it should be = a precedent for future documents without actually writing down the backing requirements and making sure they're institutionalized across the IETF organizations.

Later, Mike





_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--00000000000004ba2b061481ba7d--