Re: [arch-d] Call for Comment: <draft-iab-rfc3677bis> (IETF ISOC Board of Trustee Appointment Procedures)

John C Klensin <> Sun, 28 February 2016 20:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AC311ACD02 for <>; Sun, 28 Feb 2016 12:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6XmFHsZRQWGc for <>; Sun, 28 Feb 2016 12:19:25 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD2E71ACCFA for <>; Sun, 28 Feb 2016 12:19:25 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1aa7oK-00002d-6D; Sun, 28 Feb 2016 15:19:24 -0500
Date: Sun, 28 Feb 2016 15:19:19 -0500
From: John C Klensin <>
To: Michael StJohns <>,
Subject: Re: [arch-d] Call for Comment: <draft-iab-rfc3677bis> (IETF ISOC Board of Trustee Appointment Procedures)
Message-ID: <>
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.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Feb 2016 20:19:27 -0000

--On Sunday, February 28, 2016 15:06 -0500 Michael StJohns
<> wrote:

> I'm always somewhat pained by toothless requirements.  E.g.
> what's the downside if the IAB fails propose an update, or if
> they drag out the completion of the update for several years
> because other things are more important?

So am I.  However, my pain level about toothless requirements is
exceeded by my pain level about making specific requirements for
the handling of unusual or edge-case situations, requirements
that may not be able to anticipate all possible cases and that
therefore may overreact or under-react.   I'd like to believe
that the community has ways to hold the IAB accountable for
failing, without good reason, to do things the community told
them to do.  I'd also like to believe that the vast majority of
the IAB takes community instructions seriously enough that those
instructions will, if clear, simply be followed in the
overwhelming percentage of circumstances.    If that turns out
to not be the case and accountability mechanisms prove necessary
but ineffective in practice, and the community actually cares,
the community has a much more serious problem than whether ISOC
BoT members are appointed or a specific BCP is updated.