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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 05 October 2019 02:40 UTC

Return-Path: <brian.e.carpenter@gmail.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 52D33120047 for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 19:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4c4HZfcsihl for <ietf@ietfa.amsl.com>; Fri, 4 Oct 2019 19:40:38 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3A4120020 for <ietf@ietf.org>; Fri, 4 Oct 2019 19:40:38 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id c3so2516202plo.2 for <ietf@ietf.org>; Fri, 04 Oct 2019 19:40:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JgnzNHexwOpFeY/N3e+EbLLQbTWGWf2OyTobeG2TnLo=; b=P6pkoMCqJ3SMgCDrBcIHl0i4EkJbq+18Hg7KiD09i48oSZcBsMTSxkNCESCQLXCA8n 3uH5dFWtlVwrX3J+tKXeUJBHd8go7u4kY0E44QJIf+Gh/wYWYjpG/SQe/emGJgBGuF6q LsoDpPc33fC/WwMMTE2S+kY4X6xug238J5OujCUfwWpvY679zetLoD3O0fiQ3KiBD0Kh VJO0yDfAiXTqQ/6fGPIR0rRlSfrm5fP4eCE8yiAfzpY2SqQxUFYVULeAkP+tahmkWZEO CIZfDXcGLe4zI85WPe5IPcgvhbVu9LqPFZNxsfAE5kZxB7JOisBiUVAAPfEaV1YOLslI p4hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=JgnzNHexwOpFeY/N3e+EbLLQbTWGWf2OyTobeG2TnLo=; b=XV0yoiCyXdpHwC7zvEW2xTlqcyFV6okUgof1aQdxqQWEJPFlnm5Wq4Dpsy99vpuGGY nWd2cd5V2yuCWg84Zod1U1KcbDnUKENQNJLit5VnYKiryeHt84SN7s9bVh6P9WNq2j94 8EXGipgV+sDlowWg/jtb/ZhITt9NRTAf7H8HDrYSztJieF+hrZcubNoWefX4QKvCyxXJ c+heUmT7ixHCG8j8ZDXHIxuT2y7/ylVHigxClRf4HqeNOA+bIENTaSxtVyYRIhBOPseh Gw8WKc/Mq+XDmM8dogKrrSqQqj4Ct+40H0kLBueo6chyaihNB3Z4VtW6qintvyLFmifa M9TA==
X-Gm-Message-State: APjAAAVMZhVX0sTGsq6YQcULEVj2KpH/yrFnhBa+0SZnz7GbrHpF6K2y yQKpFsjkJx9wIzXhrDwnYTvVjwJ0
X-Google-Smtp-Source: APXvYqzA8WD9Z/mHetJ2wA6CmCmgJ8IZUT3Uvoqh3cTIVc0WWKKBLndirlkPlOtkX8dYcQEOHS6ohA==
X-Received: by 2002:a17:902:6b45:: with SMTP id g5mr4134905plt.336.1570243237551; Fri, 04 Oct 2019 19:40:37 -0700 (PDT)
Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id u9sm9738114pfl.138.2019.10.04.19.40.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Oct 2019 19:40:36 -0700 (PDT)
Subject: Re: The IETF, Standards process, and the impact on the RFC series document production
To: Michael StJohns <mstjohns@comcast.net>, ietf@ietf.org
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <3a67d528-ed48-8aa2-0514-67a8f09de76d@gmail.com>
Date: Sat, 05 Oct 2019 15:40:34 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <87a3e050-6e94-fcb0-70b8-cb907a029a0f@comcast.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XTaMrc-hTWuiBc5Rd45nwTkZLz4>
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: Sat, 05 Oct 2019 02:40:41 -0000

On 05-Oct-19 05:11, Michael StJohns wrote:
...
> On 10/4/2019 3:51 AM, Christian Huitema wrote:
...
>> Implementing our standards involves a treasure hunt
>> to find how many RFC have to be read before understanding the whole
>> picture.
> This is problematic, but inherent, not so much in the RFC series, but in 
> the way we've chosen to do our standards process. 

Bingo! Changing the RFC series *will not* fix this problem.

My favourite example of this problem is the standards process itself.
This is exactly why I originated what is now at:
https://www.ietf.org/standards/process/informal/
Read it and have a good laugh. We shouldn't underestimate the size
and complexity of the problem.

Beating an old drum (and also indirectly replying to Nico Williams),
people really do need to read the earlier work on this topic:
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd
Whatever the reasons why that document did not progress, it is
very clearly about the standards process, not the RFC series.

I've just looked back at some of my notes from 2005/2006, and what
I see is that vast amounts of IESG time (and worry) then went on things
that today are largely automated by the tracker. The same is probably
true for WG Chairs. In that context,
  "This document proposes that a new document series be created, called
   Internet Standards Documents ("ISD"s) and that these be real
   documents, separate from the underlying RFCs."
seemed pretty scary to a lot of people. So we got:
https://mailarchive.ietf.org/arch/msg/newtrk/j8Si3b0cqnQSX5a5Ee8NIVdyZg4
Maybe today we are better positioned to make progress.

   Brian