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

Michael Richardson <> Mon, 12 December 2016 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60AC612949B for <>; Mon, 12 Dec 2016 12:56:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yuWpy_zcaB5m for <>; Mon, 12 Dec 2016 12:56:38 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02AA5127058 for <>; Mon, 12 Dec 2016 12:56:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ED334200A5 for <>; Mon, 12 Dec 2016 16:14:21 -0500 (EST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id EA16563770 for <>; Mon, 12 Dec 2016 15:56:36 -0500 (EST)
From: Michael Richardson <>
To: IETF discussion list <>
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
In-Reply-To: <378400590145685410530968@JcK-HP8200>
References: <> <> <> <> <66D4FC4D5384B187F1571399@JcK-HP8200> <> <378400590145685410530968@JcK-HP8200>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 12 Dec 2016 15:56:36 -0500
Message-ID: <>
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: Mon, 12 Dec 2016 20:56:41 -0000

see inline. A great summary, just one nit which might be relevant:

John C Klensin <> wrote:
    > 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.

My understanding was that a major reason NEWTRK could not reach consensus was
that it realized that no proposal could attain IESG consensus and IETF
consensus at the same time because:
  a) IESG people didn't have cycles to engage with the community.
  b) the people selected for the IESG (and who were successful) were the
     people who could operate well with the current rules.

That is, the IESG suffered from a variation of the Innovator's Dilema.
I think that a decade later things are mostly the same, but I think that
the IESG members are generally much more self-aware about the need to
reduce their I* workload so that they can engage in other things.

{NEWTRK is approximately the same age as my son. I recall him being
an infant at a NEWTRK dinner. And he is 11 now}

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-