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

Dave Crocker <> Tue, 17 June 2008 01:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5E4E228C14E; Mon, 16 Jun 2008 18:49:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75C573A68CB; Mon, 16 Jun 2008 18:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2mKVcrlqDPMq; Mon, 16 Jun 2008 18:49:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 50FD63A6969; Mon, 16 Jun 2008 18:49:15 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m5FGhdUX010784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2008 09:43:45 -0700
Message-ID: <>
Date: Mon, 16 Jun 2008 00:44:41 +0100
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Brian E Carpenter <>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
References: <> <>
In-Reply-To: <>
X-Virus-Scanned: ClamAV 0.92/7485/Sun Jun 15 14:59:25 2008 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 15 Jun 2008 09:43:46 -0700 (PDT)
Cc: John C Klensin <>,,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Brian E Carpenter wrote:
> I think one can make a case that in some documents, use of non-RFC2606
> names as examples is a purely stylistic matter, and that in others,
> it would potentially cause technical confusion. I'm not asserting which
> applies to 2821bis, but I do assert that there is scope here for
> a judgement call and therefore the inconsistency is understandable.

Actually, Brian, scope is exactly what this judgment call is out of.

The underlying question is whether rules matter in the IETF or whether the 
IETF is subject to whatever ADs feel like declaring at the moment.

If rules do matter, then the IESG needs to follow them.  In very concrete 
terms, the IESG needs to be constrained it its application of a Discuss to 
matters of serious import and to document the basis for an application of a 

The current case has an AD asserting a Discuss by claiming a rule that does 
not exist.  That's not judgment call, that's invention.

Even better is that application of this invented rule on a revision to an 
established standard represents an orientation towards change that is 
de-stabliling rather than helpful.

With that combination, you can't get much more out of scope.


   Dave Crocker
   Brandenburg InternetWorking
IETF mailing list