Re: Services and top-level DNS names (was: Re: Update of RFC 2606

Dave Crocker <> Fri, 04 July 2008 21:52 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 621C73A69B9; Fri, 4 Jul 2008 14:52:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32DC73A67D9 for <>; Fri, 4 Jul 2008 14:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g1ziOuD7mHdg for <>; Fri, 4 Jul 2008 14:52:29 -0700 (PDT)
Received: from (unknown [IPv6:2001:470:1:76:0:ffff:4834:7146]) by (Postfix) with ESMTP id BA2F53A69B9 for <>; Fri, 4 Jul 2008 14:52:28 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m64LqOSi012083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2008 14:52:29 -0700
Message-ID: <>
Date: Fri, 04 Jul 2008 14:52:24 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: John Levine <>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
References: <>
In-Reply-To: <>
X-Virus-Scanned: ClamAV 0.92/7639/Fri Jul 4 11:44:12 2008 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Fri, 04 Jul 2008 14:52:29 -0700 (PDT)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

John Levine wrote:
>> The problem isn't just "inability to use" -- it's that other parties
>> exist who may claim the usage right, and provide citations to RFCs to
>> back up their claim.
> There are several ICANN documents describing the new process that
> include a set of recommendations to guide the process.  You must have
> read them, since you are concerned about this proposal.  Do you think
> that recommendations 3, 4, and 20 are adequate to address this
> problem?  If not, why not?

John, et al,

While I think it entirely appropriate to check whether any of us has a clue 
about what ICANN is actually doing, I do suggest that reference to a document 
warrants providing a specific citation, particularly when there are so many 
possible choices at the ICANN cite.

I'm guessing you mean:


and specifically the Recommendations table.

If so...

No. 3 is about legal infringement.  That seems wholly irrelevant to the scope of 
IETF work, although I agree that the ietf list thread has started using language 
that sounds related.

No. 4 says "Strings must not cause any technical instability." which sounds 
exactly within IETF scope covers the gist of the technical aspects of the ietf 
list discussion.

No. 20 seems to have to do with failing a popularity contest.  Probably a good 
escape clause to include, but not all that relevant to our I discussion... I hope.

Let me stress that I do think language like "claim the usage right" makes No. 3 
sound appropriate, but that the scope of IETF RFCs is technical specifications, 
rather than "rights".  While yes, one can say that reserving a name or 
proscribing against the use of a name -- such as a single, top-level label as a 
standalone name -- can be interpreting as declaring a "right", I suggest that an 
IETF discussion will fare much better by focusing on the technical issues that 
lead to the constraints, rather than attempting a quasi-pseudo-meta-legal 

Simply put:  If an IETF specification has gone through the IETF consensus 
process and been approved, the requirements and constraints imposed are almost 
by definition technical requirements.

Violating one of them invites instability, if only because it invites variable 
implementations.  At the least, treating such constraints as subject to creative 
interpretation by another body renders all output of the IETF fluid.

And just to press this to a logical conclusion, albeit not one that seems to be 
at issue... yet:  If ICANN believes that the IETF has issued a problematic 
specification, then ICANN needs to ask the IETF to fix it, rather than to have 
ICANN, or anyone else, issue a modification/clarification.



   Dave Crocker
   Brandenburg InternetWorking
Ietf mailing list