Re: Rough consensus? #425 3.5

John C Klensin <john-ietf@jck.com> Mon, 24 January 2005 18:38 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10012; Mon, 24 Jan 2005 13:38:25 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9N7-0007N2-25; Mon, 24 Jan 2005 13:55:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8y8-0007Fu-Ul; Mon, 24 Jan 2005 13:29:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8vO-0006P0-8R for ietf@megatron.ietf.org; Mon, 24 Jan 2005 13:26:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09046 for <ietf@ietf.org>; Mon, 24 Jan 2005 13:26:50 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9Bu-0006sR-UL for ietf@ietf.org; Mon, 24 Jan 2005 13:44:00 -0500
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1Ct8vE-0000wZ-UJ; Mon, 24 Jan 2005 13:26:44 -0500
Date: Mon, 24 Jan 2005 13:26:44 -0500
From: John C Klensin <john-ietf@jck.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <E19969DF07BA042BBCDE4CB2@scan.jck.com>
In-Reply-To: <tsl8y6ihn3w.fsf@cz.mit.edu>
References: <1D04D4A5E0234FFAE46AB913@B50854F0A9192E8EC6CDA126> <6.2.0.14.2.20050119112204.0585b710@pop.mindspring.com> <41EEEB6B.2060405@thinkingcat.com> <41F1A047.50608@thinkingcat.com> <076D04BEFD03EF72CECE2549@scan.jck.com> <6.2.0.14.2.20050122225421.05edbeb0@pop.mindspring.com> <0E49637477D08E4D64FF9924@scan.jck.com> <6.2.0.14.2.20050123134830.05c526a0@pop.mindspring.com> <2DBB62EA7B8D592F13E0BBF6@scan.jck.com> <tslpszv1ono.fsf@cz.mit.edu> <98235B7376B48CE881D38669@scan.jck.com> <tsl8y6ihn3w.fsf@cz.mit.edu>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit
Cc: Leslie Daigle <leslie@thinkingcat.com>, Michael StJohns <mstjohns@mindspring.com>, ietf@ietf.org, Harald Tveit Alvestrand <harald@alvestrand.no>
Subject: Re: Rough consensus? #425 3.5
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit


--On Monday, 24 January, 2005 10:18 -0500 Sam Hartman
<hartmans-ietf@mit.edu> wrote:

> I agree with you that pre-decision comments are preferable and
> that processes and procedures should allow these comments.
> 
> I also agree that the example I proposed cannot happen under
> current procedures because there is not a comment window for
> meeting locations.  I do not intend to speak to whether such a
> window would be a good idea.

Understood.  Let me only make the observation that I think it
would be better to have clear criteria that the IASA is expected
to follow than to have discussions of individual decisions,
either before or after the fact.  One of the reasons is that,
for some sites that might otherwise be completely reasonable,
having it be known that the site was considered and then
rejected might turn out to be an embarrassment for the site
and/or the IETF and such things should be avoided when possible.

> However, failure to take adequate comments before making a
> decision seems like a reasonable justification from my
> standpoint for reviewing that decision.  Depending on the
> consequences of doing so it may even be appropriate to reverse
> such decisions.  There is significant but *not infinite* cost
> to reversing a decision.  There can also be significant cost
> to having a bad decision.  There is also a cost to the review
> process itself.

This may go to the core of the difference in my position and
yours.   Let's review the composition of the IAOC.   The IETF
and IAB Chairs are members.  If the are doing their jobs there,
they are aware of decisions before they are made, can argue the
IAOC to establish appropriate rules for the IAD to engage in
consultation before a decision is made, and so on.  If they are
dissatisfied with the amount of review a pending decision is
getting, they can request reviews or reconsideration internally,
take the issue up with the IAB or IESG which might then demand a
review, or even initiate an IETF-wide discussion about recalls.
Conversely, if they fail in those regards and decisions are made
without adequate comments and that fact takes the IETF community
by surprise, then perhaps they should be the first people
recalled.  

I'm making an assumption here which might not be valid.  I'm
assuming that, generally, possible IAOCs will fall into one of
two categories.  One --the one we want-- will be open and
transparent whenever possible, will try to design things to
allow for community input before decisions are made whenever
possible, and will try to establish principles, in conjunction
with the community, about how things should be done and then
follow them.  At the other extreme, one might imagine an IAOC
that tried to do everything in secrecy, that was relatively
insensitive to community input, and that tried to arrange its
decision-making processes (and that of the IAD) so that there
was as little opportunity for distracting input or comment as
possible.    I think it is extremely unlikely that we would end
up with an IAOC that would be open about some things but as
secretive as possible about others, at least unless the openness
was used as a deliberate cover for the secrecy.

Now, in my view, the problem of the second or third styles of
IAOC operation is not solved by better techniques for reviewing
and/or changing individual decisions.  The solution is replacing
the IAOC membership (serially if needed) with a group that will
"get" the notion of being open and responsive to the IETF
community.   If we all understand that the expectation of the
IAOC is as much openness and opportunity for comment as is
possible and sensible given the particular issue, and we hold
the IETF-appointed members of the IAOC (including especially the
two Chairs) responsible for reminding the IAOC about that norm,
then we won't need post-decision reconsideration procedures for
individual decisions.  Conversely, if the IAOC doesn't act
according to that norm, we should focus on that fact and fixing
it (in a hurry) and not on the particular decisions that
result... if only because a good decision that is made without
adequate opportunity for contact is as much of a problem as a
bad decision made under the same circumstances.

> Question: do you see cases where if a problem developed we'd
> be unable to deploy safeguards fast enough or unwilling to
> deploy the safeguards even given an actual instead of
> theoretical problem?  How likely do you see these situations?

I think it is up to the Nomcom and to the IAB.  The IETF
community's main insurance against IAOC misbehavior with regard
to decision-making is the presence of the two Chairs on the IAOC
and how those people behave, not provisions of the BCP.  Were
the two Chairs to start behaving as if they took their
instructions and guidance direct from some deity, rather than
from the community, the IAB and the IESG, and to encourage the
IAOC to behave on a similar basis, then I can imagine all sorts
of problems that none of the safeguards we have discussed would
help solve quickly.  But it is unlikely that such behavior would
catch up by surprise and, if the members of the IESG and IAB
remember their responsibilities to the community if some of
their members start misbehaving seriously, we presumably don't
need additional mechanisms.

      john



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf