Re: I-D Action: draft-wilde-updating-rfcs-00.txt

Brian E Carpenter <> Mon, 12 December 2016 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 845B7129857 for <>; Sun, 11 Dec 2016 16:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lp5WwKwDS3R6 for <>; Sun, 11 Dec 2016 16:39:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DA33129854 for <>; Sun, 11 Dec 2016 16:39:20 -0800 (PST)
Received: by with SMTP id f188so28838123pgc.3 for <>; Sun, 11 Dec 2016 16:39:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=AOh6bPhHYDs29r3DlJvD/UOyQKALYNQfDMMkQhsdV9k=; b=v1bxSmK0WkgpnLpw8DJo5QXR6y5YIJCRRwlyYfCUjVuDI7MizvGWW5yeTtbYkzdL4z L9T1GNnTNhBUASrlExM/43nhXALLZeRaPPUIuj8HD8VmWCieFikH9tFv+MKjzlwyNYGK vR4jt8JjdSw0bMUeymu67fBBV5gQTaLvcsd5LAzl14thBOPnAZwHOuXPQdyQMcHU8lbk Iv95Q3ks025nTNt+/CFm9O4QIZuDrScT1Psq0erUt4dh2Kyv3SigdVIUCrqOOwcvFW3n jczM5cmpfIyLbVdvuLuOjhg4q5DOwTREQVIEFVHUKuwYXj1pCoxpZmxr08xSxHuXteBQ 29ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=AOh6bPhHYDs29r3DlJvD/UOyQKALYNQfDMMkQhsdV9k=; b=mHvjgP2V+K/wK4neJ4WXpo18xRCbk9HNeINjp9HZXeWFFKPe1Rx26LuRHC7FFpdZDH UEzQdaEcieHL2Izn7DutWGZShelWxwnCw8HcSS+kdXn0i+P3VwnASPRfnl/Y5uCnvuwI 7XjtQwf1bn/sUNc21NAAnTyD7cyOgie6pcnRSbd2dFJBUseG5RbnEP4pqzH3WWiyQNwe n/0d/WqaWoeHMvkQLTkWWWD5n8YVba+hLLbZmvYyqeM5Ltnyxw6FmYtV3+tf9rnAsTOZ Cmxd3ckk2fGQzfGpeeH85saAVDPvJ189i4PM3MhKYFNTLnLj5Y/7nAar34reXVptV06V jqqg==
X-Gm-Message-State: AKaTC01SFI6tNcZ0Q9fUF83yAyremMeqqKwX0ABXiR7pHsyOca6NrGwtclOByoIxO4cAAg==
X-Received: by with SMTP id g17mr163292239pgi.80.1481503160035; Sun, 11 Dec 2016 16:39:20 -0800 (PST)
Received: from ?IPv6:2406:e007:4eed:1:28cc:dc4c:9703:6781? ([2406:e007:4eed:1:28cc:dc4c:9703:6781]) by with ESMTPSA id t67sm72065192pfg.13.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Dec 2016 16:39:19 -0800 (PST)
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
To: "Scott O. Bradner" <>, Erik Wilde <>
References: <> <> <> <> <66D4FC4D5384B187F1571399@JcK-HP8200> <> <378400590145685410530968@JcK-HP8200> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Mon, 12 Dec 2016 13:39:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF discussion list <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Dec 2016 00:39:22 -0000

On 12/12/2016 10:23, Scott O. Bradner wrote:
> see, for example,

And while we're reviewing ancient history, let me say that the new IESG in 2005,
with me as the new Chair, did spend hours discussing that draft and failing to
reach a useful consensus. But not because we thought there was no problem. As I've
said more than once, there is a problem, for any protocol that is complicated enough
to need several interlocking RFCs to define it. As those various components require
updating, we grow a dependency tree. The "Updates" tag on the more recent RFCs is a
very coarse way of expressing the dependencies.

Requiring the updating RFC to be clear about why and how it is updating other RFCs
is IMHO a good idea. However, I don't think that a mandatory section in the updating
RFC is the right way to ensure this. It would just become a box-ticking exercise.


> Scott (network WG chair)
>> On Dec 11, 2016, at 2:22 PM, John C Klensin <> wrote:
>> Erik,
>> Sorry for the delay in responding. Let me try a very high-level
>> summary of the implications of what I, at least, consider the
>> most important history of the problem you are trying to bite off
>> a piece of (others will have other histories).  First, it isn't
>> easy.  Even if one just ignores the various flavors of
>> Informational documents, the right documentation rules for
>> single-stage processes (e.g., BCPs) are inevitably different
>> from those for two (and previously three)-stage technical
>> standards track ones.  That problem is further complicated by
>> the fact that we use BCPs, and occasionally technical standards,
>> for what are really procedural or policy statement documents.
>> Second, there is a complexity tradeoff.  Today, for normative
>> documents, we have BCP documents and 2 1/2 levels of standards
>> track  one (depending on what one thinks Experimental is).  
>> The issues of updating and categories are also inevitably
>> complicated by the nearly-orthogonal one of interrelated and
>> interdependent documents, some developed at different times and
>> by different groups and often with non-obvious overlaps.
>> We tried to take all of this on some years ago in a WG called
>> "NEWTRK".  It was not successful.  In particular (and trying to
>> state this as neutrally as I can manage), the WG concluded that
>> we needed a new type of Standards Track document that would talk
>> about status and relationships among documents, rather than
>> being one or more technical specification itself.  At least some
>> of what you seem to be proposing would go into those
>> standards-description documents and not the technical
>> specifications themselves.  In addition, at least some of us
>> believe that the relevant documents would be living documents
>> with change histories rather than the inherently-static (at
>> least per-document) RFC series.  
>> WIthout revisiting the argument and various opinions about
>> motivations, the IESG concluded that the idea was just too
>> complicated and/or inappropriate and the idea when nowhere.  In
>> retrospect, they might have been right.  Or not.  Either way,
>> the experience left many of us reluctant to start nibbling at
>> the issues again unless there was a comprehensive plan that the
>> IETF was willing to sing off on.
>> However, I do believe that it is unrealistic to believe one can
>> take on inter-document relationships without at least reviewing
>> the issues that the NEWTRK WG examined and the options it
>> considered.
>> best,
>>    john
>> --On Wednesday, December 07, 2016 21:52 -0800 Erik Wilde
>> <> wrote:
>>> hello john.
>>> On 2016-09-15 09:37, John C Klensin wrote:
>>>> Independent of where it is discussed (as
>>>> long as it is on a public list), this I-D would be, at least
>>>> IMO, a much more satisfactory basis for discussion if it
>>>> demonstrated more convincingly that the author was aware of
>>>> those earlier discussions and had considered them, rather than
>>>> assuming (or appearing to assume) that no one had thought
>>>> about these topics.
>>> it was not my intention to ignore or belittle previous
>>> discussions. it just occurred to me as a frequent reader of
>>> RFCs that there is a large variation in quality how updates
>>> are documented. the idea was that some simple documentation
>>> guidelines might help to improve that, without necessarily
>>> being hard definitions on what exactly updates are, and how
>>> exactly they have to be documented.
>>> i'd be more than happy to include these earlier discussions,
>>> but i am afraid if that involves going through a long list of
>>> mail archives, this simply is beyond the time commitment i can
>>> reasonably make. i'd be more than happy to have somebody
>>> co-authoring and filling in those gaps, but that of course
>>> assumes that somebody else would be willing to put in the
>>> effort of writing up this history.
>>> thanks and cheers,
>>> dret.