Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Dave Crocker <> Thu, 26 June 2008 09:46 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BEE3D28C154; Thu, 26 Jun 2008 02:46:55 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D21FE28C149; Thu, 26 Jun 2008 02:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.637
X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, SARE_RMML_Stock10=0.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NUCyNGt7x1OR; Thu, 26 Jun 2008 02:46:51 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:76:0:ffff:4834:7146]) by (Postfix) with ESMTP id 07C3028C108; Thu, 26 Jun 2008 02:46:50 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m5N97nPp018772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 02:07:54 -0700
Message-ID: <>
Date: Mon, 23 Jun 2008 09:09:19 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Russ Housley <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
References: <> <> <p06250116c47c330c7dd0@[]> <> <C122F91B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM> <> <> <>
In-Reply-To: <>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Mon, 23 Jun 2008 02:07:55 -0700 (PDT)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

(re-posted, since the original apparently went out with an unsubscribed From: /d)


Russ Housley wrote:
> I'm not sure I did a wise thing by joining the discussion, but in for 
> a penny, in for a pound ...

What I am seeing is a thread that had some bits of silliness, early on, but has
moved into serious, thoughtful efforts to put forward serious, albeit differing,
points of view.  Under those conditions and in terms of immediate and long-term
IETF health, I am quite sure it is wise for the principals of the current
situation to participate in a public exchange of this type:  After all, the IETF
is supposed to be about collaboration among equals.

Collaboration does not have to begin with agreement, but it does have to begin.
Having one or another party sit quietly off to the side hurts mutual
understanding and, therefore, mutual comfort in the outcome.

(I'll note that I found the latest postings by Ted Hardie and Robert Elz to be
compatible with my own views and particularly well written. I found them worth

> The first hint of this issue surfaces during Last Call. 
> When I highlighted this paragraph, the document PROTO shepherd 

As soon as discussion needs to review the timeline of the disagreement, we
probably have a prima facie basis for suspecting a problem with the process, not
just the people.  The reason is that such a review tends to turn into a debate
about what happened when, rather than about the substance of the Discuss.

I suspect there are ways to improve the mechanics of the process leading up to
and following a Discuss.  I'm not sure what those are, but the current mechanics
tend to favor informal, private exchanges which in turn favors limited, mediated
information and limited review.  These are not good for ensuring community
buy-in or, for that matter, the quality of the outcome.

I think that informal, private exchanges have an important role to play, because
their personal dynamics is far less charged than a public exchange.  But I
suspect the current mechanics could greatly benefit from being more public.

A simple suggestion that might help is that an Area Director who issues a
Discuss could be required to post their reasons to the working group mailing
list and be obligated to engage in a... discussion... about it, starting with a
careful explanation of their justification for blocking approval.

> Upon detailed study, I see that the paragraph could be more 
> clear.  I've asked the author if he is willing to propose revised 
> text.  Vacation schedules will keep this from happening in the next few days.

At base, it is clear that the current appeal is not about John's willingness to
make changes.

It is about the application of a Discuss to force this kind of change and the
claim that formal authority for it is lacking.

>> If you feel that group was rogue, please explain.  If you do not, 
>> what is the basis for your view that its considerations were 
>> sufficiently faulty to warrant being overridden?
> Prior to the appeal, this aspect of John's rationale was not 
> raised.  It was not raised by John, the document PROTO shepherd, or 
> the IESG member sponsoring the document.

Again, I hope we do not find ourselves in a he said/no he didn't exchange.  I'll
merely suggest that had the Discuss been immediately taken to the public mailing
list, it seems pretty likely that salient details would quickly have been put

Again: having these authority-related exchanges be private makes them extremely
fragile and subject to problematic outcome.  Limited perspectives.  Partial
information.  Likelihood of entrenched positions. All of that disappears --
well, ok, maybe not, but at least it's reduced -- when the working group is
brought into the mix directly -- not mediated by a chair or author.

> That seems to be the crux of the appeal.  Does every possible thing 
> upon which an AD can raise a DISCUSS position need to align with a 
> written rule?  Don't we select leaders because we have some 
> confidence in their judgement?

If we are to have detailed rules, yet allow deviations from them, then what is
the point of the rules?

My own guess is that the real question is not about confidence in judgment but
about the types of judgment that should be called for.

I believe that a collaborative process which empowers a single person to block
progress is broken in a very fundamental way.

The premise of an open, collaborative process like the IETF has is that no
individual's view/opinion is definitive. The most knowledgeable, most skilled
and best-intentioned person has a bad day.  Poor judgment even within their area
of expertise, nevermind outside it.

In an IETF environment, choice is directed by the ability to garner group
support. This has direct long-term benefit: A choice dictated by a minority will
not have broad-based support.  One which really does represent rough consensus
has already overcome the major barrier to adoption:  a critical mass of the
community agrees with it.

We have a long-standing exception to this, when we ask IESG members to exercise
veto authority.  It sets one person's expertise against that of the folks who do
the work.  Worse, it is exercised at the end of their considerable effort.  In
the context of an IETF, this is strikingly dissonant.

Contrast this with the view that the considerable judgment of IESG members is
not for saying yes or no, but for raising flags.  It takes quite a lot of
skilled judgment to see when there is an embedded, subtle problem with a
specification.  And it takes quite a lot of skilled judgment to be able to
communicate this problem to the community, so that the community itself can form
rough consensus about the problem -- and the solution.

My view has been that was the intent behind choosing the word "Discuss" rather
than "No" or "Veto".

I happened to be on the IESG at the time.  While it was clear even then that
some specifications weren't salvageable, it was also clear that the job of
management in an IETF community was to facilitate development of community
understanding and decision, rather than to exercise raw authority.  (But then,
we were just coming off of the IAB Kobe debacle and were rather sensitive to the
exercise of authority.)

Let me suggest something radical:

      Let's have fewer rules, not more of them.  With fewer rules, there is a
greater burden to explore and negotiate legitimate concerns carefully and

      But if we are going to have detailed rules, let's follow them.



   Dave Crocker
   Brandenburg InternetWorking
IETF mailing list