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

"Scott O. Bradner" <> Sun, 11 December 2016 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EE5F1297C3 for <>; Sun, 11 Dec 2016 13:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zYRwiRZSz8lE for <>; Sun, 11 Dec 2016 13:23:20 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A52412950B for <>; Sun, 11 Dec 2016 13:23:20 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D02AC35032D1; Sun, 11 Dec 2016 16:23:18 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 67_u9tQSL1jJ; Sun, 11 Dec 2016 16:23:17 -0500 (EST)
Received: from [] ( []) by (Postfix) with ESMTPSA id B1D9335032BF; Sun, 11 Dec 2016 16:23:17 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
From: "Scott O. Bradner" <>
In-Reply-To: <378400590145685410530968@JcK-HP8200>
Date: Sun, 11 Dec 2016 16:23:14 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <66D4FC4D5384B187F1571399@JcK-HP8200> <> <378400590145685410530968@JcK-HP8200>
To: Erik Wilde <>
X-Mailer: Apple Mail (2.3251)
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: Sun, 11 Dec 2016 21:23:22 -0000

see, for example,

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.