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

John C Klensin <> Tue, 13 December 2016 03:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F230712955E for <>; Mon, 12 Dec 2016 19:47:39 -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 jG2f9NtVbJLc for <>; Mon, 12 Dec 2016 19:47:38 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2ACAC129572 for <>; Mon, 12 Dec 2016 19:47:38 -0800 (PST)
Received: from [] (helo=JcK-HP8200) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cGe3y-000IDa-Fo; Mon, 12 Dec 2016 22:47:34 -0500
Date: Mon, 12 Dec 2016 22:47:29 -0500
From: John C Klensin <>
To: Brian E Carpenter <>
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
Message-ID: <E186A6708FBC8836D0DC4655@JcK-HP8200>
In-Reply-To: <>
References: <> <> <> <> <66D4FC4D5384B187F1571399@JcK-HP8200> <> <378400590145685410530968@JcK-HP8200> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: Michael Richardson <>, 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: Tue, 13 Dec 2016 03:47:40 -0000

--On Tuesday, December 13, 2016 11:06 +1300 Brian E Carpenter
<> wrote:

> I think this illustrates the dictum that "there is always a
> well-known solution to every human problem — neat,
> plausible, and wrong." [HL Mencken, 1917]. It's not that it
> wouldn't clarify the exact status of certain RFCs - but it
> would hardly scratch the surface of the underlying standards
> spaghetti.
> IMHO, the problem tackled in
> 04 is too complex to be fixed by simple measures.
> It's also worth looking at this (out of date) example:
> oc-00
> Anybody up for newnewtrk?

Alternate proposal:  IIR, the IESG never did a write up or
initiated a Last Call on that proposal despite a request from
the WG to do so.   They simply announced that they were not
going to consider it, an action that is dubious under RFC 2026
but not prohibited.  Some of us who were active in Newtrk
assumed that, if there was a Last Call and fairly clear
community consensus, the IESG would be in an intolerable
position if they decided to advance the document, but that is
just speculation.

As co-author of,
I'd be happy to find time to update references and boilerplate
and reissue it if the community wants to take it up and the IESG
is willing to given it serious consideration, either on the
basis of the Newtrk recommendations or through some restarted

Where I think I agree with Brian is that this is a complicated
issue and that a new rule or required paragraph will make things
even more complicated without improving things.