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 A901C3A67B7; Mon, 16 Jun 2008 18:49:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 595873A69E0; 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 dniepr+zZn4Z; Mon, 16 Jun 2008 18:49:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F4943A6874; Mon, 16 Jun 2008 18:49:12 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m5G04h2U018044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2008 17:04:50 -0700
Message-ID: <>
Date: Mon, 16 Jun 2008 08:05:47 +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/7488/Sun Jun 15 23:06:58 2008 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 15 Jun 2008 17:04:53 -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:
>     However, I'm arguing that
> there is scope on this particular point for concluding that there is
> a *technical* issue (a source of confusion, i.e. a lack of clarity).

If would be fascinating to see someone attempt to defend such a claim 
seriously and with pragmatic substance, rather than detached theory.

That is, to try to prove the claim with facts.

> That may or may not be a valid conclusion. 

And that's one of the issues that is that the meat of the appeal, as I read 
it:  The serious basis for the Discuss has not been documented, nevermind 
defended.  So we can debate all sorts of hypotheses about whether their might 
or might not have been a legitimate basis for this Discuss, and we would 
thereby miss the underlying issue.

> However, one of the two
> DISCUSS comments points out that at least 3 of the domains used are
> real ones. So the issue of confusion is a real one. 

1. Where is the rule prohibiting the use of real domain names?

2. This particular spec began life 25+ years ago using those names, so we 
ought to have solid data showing that that particular document's use of those 
names is a problem.  Where is it?

3. Where is the empirical substantiation that use of a real domain name in an 
  RFC spec causes problems with the development of interoperable implementations?

4. If you want to focus on a judgement call, how about focusing on the 
judgement that keeping specification documents stable, as much as possible, 
across their life, is important?

> What I am
> saying is: these DISCUSSes are about a technical issue. They may or
> may not be reasonable, but I object to the suggestion that they are
> stylistic or editorial (which would automatically make them out of
> scope under the IESG's own document).

Like any good technical issue, I'm sure you can document the real-world 
demonstrations of this as a problem and for this document?

Mostly what you are doing, Brian, is demonstrating that one can claim that 
anything is a technical issue.

>> 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.
> I don't think that changing to would
> destabilise the email system too much.

Perhaps you are missing the point.

I guess that's a judgement call, too.


   Dave Crocker
   Brandenburg InternetWorking
IETF mailing list