Re: The IETF, Standards process, and the impact on the RFC series document production

Nico Williams <nico@cryptonector.com> Fri, 04 October 2019 17:42 UTC

Return-Path: <nico@cryptonector.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 4A61512011F for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 10:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thQVGIyOnl9l for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 10:42:29 -0700 (PDT)
Received: from crocodile.birch.relay.mailchannels.net (crocodile.birch.relay.mailchannels.net [23.83.209.45]) (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 3B4961208EA for <ietf@ietf.org>; Fri, 4 Oct 2019 10:42:27 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2C7A62C2318; Fri, 4 Oct 2019 17:42:27 +0000 (UTC)
Received: from pdx1-sub0-mail-a2.g.dreamhost.com (100-96-35-142.trex.outbound.svc.cluster.local [100.96.35.142]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8B4CB2C2410; Fri, 4 Oct 2019 17:42:26 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a2.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Fri, 04 Oct 2019 17:42:27 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Lonely-Language: 24a14634617e2005_1570210946968_1341313450
X-MC-Loop-Signature: 1570210946968:2521113868
X-MC-Ingress-Time: 1570210946968
Received: from pdx1-sub0-mail-a2.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a2.g.dreamhost.com (Postfix) with ESMTP id 1254C8274F; Fri, 4 Oct 2019 10:42:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=w2PA9oCidATnp0 9M1kdqQsBztcc=; b=Lp79JufA6bJeBh71o4O1EmnmzjtvFQ6r3/X6TaeNFVDS3E wYEodC1KOmrvX1VLuKZ12ZWFmAobD67WkHHioPFKFPwq3mPtGmlPyZYas46aAvuJ InSCjGEy5kBkayK0jcgfcatZV1gHKGWmf/wymjFMjZZzc61P06a4n6gjCAv5M=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 960B582748; Fri, 4 Oct 2019 10:42:23 -0700 (PDT)
Date: Fri, 04 Oct 2019 12:42:20 -0500
X-DH-BACKEND: pdx1-sub0-mail-a2
From: Nico Williams <nico@cryptonector.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Michael StJohns <mstjohns@comcast.net>, ietf@ietf.org
Subject: Re: The IETF, Standards process, and the impact on the RFC series document production
Message-ID: <20191004174220.GH5002@localhost>
References: <394203C8F4EF044AA616736F@PSB> <4097464f-d038-2439-5ca5-70bac46b25ea@huitema.net> <69DAA6BBBE243BAD98926154@PSB> <371c3b14-8bfc-a476-3ff9-7268485bad12@huitema.net> <87a3e050-6e94-fcb0-70b8-cb907a029a0f@comcast.net> <20191004164815.GG5002@localhost> <CD23F5236075A5EB09DBF350@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CD23F5236075A5EB09DBF350@PSB>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrhedugdduuddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lgGnaheloLaJaFEGzjdvtsuH-9g>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <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: Fri, 04 Oct 2019 17:42:31 -0000

On Fri, Oct 04, 2019 at 01:07:57PM -0400, John C Klensin wrote:
> --On Friday, October 4, 2019 11:48 -0500 Nico Williams
> <nico@cryptonector.com> wrote:
> > We could design such a naming scheme and bolt it onto the
> > existing RFCs, much like STDs have distinct (and stable)
> > numbers from the RFCs that back them.
> > 
> > E.g., we could have names like:
> > 
> >   STD-DNS-xx
> >   RFC-DNS-xx-vv
> > 
> >   STD-PKIX-xxx
> >   RFC-PKIX-xxx-vv
> >...
> 
> I won't try to spend the time today to explain why that would
> cause a different set of problems other than to note that we

Maybe you can try tomorrow then?  I don't see any obvious problems.

> often process documents that don't fall neatly into one category
> and that would just cause other arguments and uncertainties.

I don't see how that's an issue.  Those can just get a plain ol' RFC
number.

>      [...].  There were similar, earlier proposals for grouping
> and status documents, as well as attempts to get more effort
> into Applicability Statements with the same intent.  All of
> those efforts met the same fate: the IESG wasn't interested in
> them or willing to initiate IETF Last Calls.  And no one in the
> community was willing to press that, e.g., by appealing the
> IESG's non-action of WG Last Call requests, at least in part
> because of concern that the appeal process would be damaging to
> the community and that the IESG would, even if they were told to
> rethink the decision, either reaffirm it or figure out other
> ways to kill an idea they didn't like.

Perhaps so, but a) the IESG is not an unchanging body, b) this seems
like as good a time as any to bring this up again.  If no one cares for
this, then no one cares for this.  Let's see.

Nico
--