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

John C Klensin <john-ietf@jck.com> Fri, 04 October 2019 19:48 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 176671200B4 for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 12:48:48 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 rEFvGx9k9NvI for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 12:48:46 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 2E321120025 for <ietf@ietf.org>; Fri, 4 Oct 2019 12:48:46 -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 1iGTZD-000K2R-5j; Fri, 04 Oct 2019 15:48:43 -0400
Date: Fri, 04 Oct 2019 15:48:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: Nico Williams <nico@cryptonector.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: <0DA8661C532CEDFA2D117C50@PSB>
In-Reply-To: <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> <20191004174220.GH5002@localhost>
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/BAQ_QYjbDrbPUSMNDH5zShmEe4s>
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 19:48:48 -0000

--On Friday, October 4, 2019 12:42 -0500 Nico Williams
<nico@cryptonector.com> wrote:

> 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.

Nico,

Mike's examples of the ITU-T and IEEE 802.x problems should be
suff9icent to put your naming proposal to rest, but let me add
two examples of the sort of question I was thinking about.   

(1) RFCs 5890-5894 and maybe 5895 and others are collectively
known as "IDNA2008".  Do they become RFC-IDNA-nn or, given what
they do, RFC-DNS-nn?  And are other documents that specify
special characteristics or syntax for DNS labels become part of
RFC-DNS-nnn or are they separate?  Similarly, are DNSSEC and the
various encrypted DNS query specs and proposals properly
RFC-DNS-nn or do they get their own subseries?

(2) There are interesting dependencies among PRECIS work, IDNA,
specifications for language negotiation, language tag and media
type specifications, and the several interdependent
specifications for non-ASCII email addresses.  If each
specification get a single number --regardless of which
sub-series it is associated with -- then the system breaks down
with regard to the other groups.  In particular, are the latter
group part of email or part of some more or less generic I18n
category?

I think any way you would go with this would either require
drastic changes in how we do standards or would turn out to
create as much confusion as it solved.

>...
>>      [...].  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.

I don't believe the IESG's willingness to actively encourage and
process proposals for significant process changes, at least ones
that that they did not originate, have changed much and might
have gotten worse.  But I do care and maybe some others do, so
let me pose a question: if any ADs would like to see either the
NEWTRK "ISD" or the related most recent "assign STD numbers at
Proposed Standard" I-D reposted so they could either sponsor
them or start a serious effort to launch a "reform the standards
process" WG, would they please speak up?   And, if they don't, I
would encourage people who care about this issue to either
volunteer for the IESG or at least be willing to speak to the
Nomcom about its importance.

best,
   john