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

John C Klensin <> Sun, 11 December 2016 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B6912946A for <>; Sun, 11 Dec 2016 11:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MyxqwK5awBky for <>; Sun, 11 Dec 2016 11:22:51 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4AAF12945D for <>; Sun, 11 Dec 2016 11:22:50 -0800 (PST)
Received: from [] (helo=JcK-HP8200) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cG9hr-000FCc-1O; Sun, 11 Dec 2016 14:22:43 -0500
Date: Sun, 11 Dec 2016 14:22:37 -0500
From: John C Klensin <>
To: Erik Wilde <>
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
Message-ID: <378400590145685410530968@JcK-HP8200>
In-Reply-To: <>
References: <> <> <> <> <66D4FC4D5384B187F1571399@JcK-HP8200> <>
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-Scanned: No (on; SAEximRunCond expanded to false
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 19:22:53 -0000


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


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