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

John C Klensin <> Thu, 15 September 2016 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0313E12B498 for <>; Thu, 15 Sep 2016 10:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hIXPopT6oZ90 for <>; Thu, 15 Sep 2016 10:07:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C553C12B8DC for <>; Thu, 15 Sep 2016 09:37:24 -0700 (PDT)
Received: from [] (helo=JcK-HP8200) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1bkZf5-000CtB-Q0; Thu, 15 Sep 2016 12:37:19 -0400
Date: Thu, 15 Sep 2016 12:37:14 -0400
From: John C Klensin <>
To: "Joel M. Halpern" <>, "Andrew G. Malis" <>, IETF discussion list <>
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
Message-ID: <66D4FC4D5384B187F1571399@JcK-HP8200>
In-Reply-To: <>
References: <> <> <> <>
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: <>
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: Thu, 15 Sep 2016 17:07:42 -0000

--On Thursday, September 15, 2016 11:13 -0400 "Joel M. Halpern"
<> wrote:

> As the draft is probably about IETF process, not RFC Editor
> rules, I would think that would be the venue for
> discussing the draft,

I concur with Joel about the above.   

Note that there have been multiple discussions on the topics of
"what does 'updates' mean" and "what should saying 'updates'
require" with the RFC Editor and, at least as few times, with
the IESG in the last decade or so.   My recollection is that
there have also been a few discussions of the same topic on this
list, mostly during Last Call discussions about the adequacy of
various documents and the closely-related topic of what it means
to have a normative reference to an obsoleted document or an
updated section of an earlier one.   Those discussions have
exposed another issue, which is that we have no way to obsolete
a section (even an appendix) of a document, only to update it to
deprecate that section.  

There are also some interactions between this work and the late
NEWTRK efforts whether one views the failure of those efforts to
be a good thing or, at the other extreme, an abuse of power by
the IESG and a significant loss to the community.  However, one
obvious lesson from that work is that our failure to be specific
about something in a BCP sometimes indicates that we have made
an effort to agree and failed, rather than that we have not
considered the issue.

NEWTRK aside, it is not clear to me that any of those
discussions have reached any conclusion, almost certainly not a
conclusion that has been put through Last Call or otherwise
gotten to a stage where anyone could claim community consensus
around the conclusions.  It appears to me that several of them
suggest that being precise about what is changed or what
sections of earlier documents are affected is at least as
important as the "reason for changes" on which the current I-D
appears to be focused.  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.