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

Dave Cridland <> Wed, 18 June 2008 20:23 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id D1E263A6A71; Wed, 18 Jun 2008 13:23:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D01C03A6ADE for <>; Wed, 18 Jun 2008 13:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 77bXoLSiUljW for <>; Wed, 18 Jun 2008 13:22:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 48E5B3A6A71 for <>; Wed, 18 Jun 2008 13:22:57 -0700 (PDT)
Received: from invsysm1 ( []) by (submission) via TCP with ESMTPA id <> for <>; Wed, 18 Jun 2008 13:33:57 +0100
Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
References: =?US-ASCII?Q?=3D=3FUS-ASCII=3FQ=3F<8832006D4D21836CBE6D?= =?US-ASCII?Q?469@klensin-=3F=3D_=3D=3FUS-ASCII=3FQ=3Fus.vbn.inter-touc?= =?US-ASCII?Q?.net><485590E2.3080107@gmal=3F=3D_=3D=3FUS-ASCII=3FQ=3Fco?= =?US-ASCII?Q?><p06250116c47c330c7dd0@[]=3F=3D?= <> <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110> <23618.1213785541.031305@invsysm1> <059901c8d132$d65df170$0a00a8c0@CPQ86763045110> <23618.1213788490.265871@invsysm1>
In-Reply-To: <23618.1213788490.265871@invsysm1>
MIME-Version: 1.0
Message-Id: <23618.1213792442.119204@invsysm1>
Date: Wed, 18 Jun 2008 13:34:02 +0100
From: Dave Cridland <>
To: <>
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

On Wed Jun 18 12:28:10 2008, Dave Cridland wrote:
> Therefore, to cover this particular case, such a blanket policy  
> would  have to be stated such that even vague recommendations in  
> BCPs

I received a private comment which appeared to suggest I'm being  
unclear here. So let me clarify:

The BCP, RFC 2606, as a whole is not a vague recommendation, and I  
certainly didn't say that - the BCP states that the domains are  
reserved, and, by its status as a BCP, it therefore reserves them.  
(Donald Eastlake said elsewhere in the thread that the reason it's a  
BCP at all was because the reservation of the domains needed the kind  
of solid consensus that BCP status provides).

What is very much a vague recommendation is whether these domains  
should be used.

The document says:

	Depending on the nature of
   the test or example, it might be best for it to be referencing a  
   permanently reserved for such purposes.

Yes, folks, that's "might be best" - hardly the eleventh commandment,  


      ".example" is recommended for use in documentation or as  

Note that both these, the latter of which is by far the strongest  
recommendation in the document, refer to the rarely used ".example"  

On the subject of the more traditionally used second-level domains,  
it says only this:

   The Internet Assigned Numbers Authority (IANA) also currently has  
   following second level domain names reserved which can be used as

So to summarize, if the IESG were saying that this phrasing forms a  
policy that all technical specifications MUST only use the domains  
from RFC 2606 - not that it is, but if it were, it would seem odd  
that the outcome would be that the IESG would recommend the second  
level domains in Section 3, rather than the TLD which seems to have  
been more strongly recommended in the consensus backed document that  
the IESG would be citing.

But that's not the point here, really - there is no such documented  
policy, and the policy we don't have is quite clearly not specified  
in the BCP that doesn't define it. At best, the BCP which does not  
define the policy we don't have suggests a different policy we don't  
have either would be a better policy to have, yet this alternate  
policy is not, as far as I can tell, what the community would  
generally want - so it's actually quite lucky that neither policy the  
BCP doesn't define actually exists.

I hope that's clearer now.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
IETF mailing list