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

Mark Andrews <Mark_Andrews@isc.org> Fri, 04 July 2008 22:42 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FAD3A6893; Fri, 4 Jul 2008 15:42:49 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456013A67D9 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 15:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.445
X-Spam-Level:
X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_00=-2.599, MANGLED_GOOD=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yYvgmMbPmMf for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 15:42:47 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by core3.amsl.com (Postfix) with ESMTP id 1B0C53A6893 for <ietf@ietf.org>; Fri, 4 Jul 2008 15:42:45 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m64MgbrY061336; Sat, 5 Jul 2008 08:42:37 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200807042242.m64MgbrY061336@drugs.dv.isc.org>
To: dcrocker@bbiw.net
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
In-reply-to: Your message of "Fri, 04 Jul 2008 14:52:24 MST." <486E9B98.6040602@dcrocker.net>
Date: Sat, 05 Jul 2008 08:42:37 +1000
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 
> 
> 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:
> 
> <http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm#_Toc43
> 798015>
> 
> 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 langu
> age 
> 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 iet
> f 
> list discussion.

	We need "cannot be used in a manner that causes technical
	instablitity.  Known causes include, but are not limited
	to, adding A, AAAA and MX records at the zone apex."
 
> No. 20 seems to have to do with failing a popularity contest.  Probably a goo
> d 
> 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 specification
> s, 
> 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 tha
> t 
> lead to the constraints, rather than attempting a quasi-pseudo-meta-legal 
> discussion.
> 
> Simply put:  If an IETF specification has gone through the IETF consensus 
> process and been approved, the requirements and constraints imposed are almos
> t 
> by definition technical requirements.
> 
> Violating one of them invites instability, if only because it invites variabl
> e 
> implementations.  At the least, treating such constraints as subject to creat
> ive 
> 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 hav
> e 
> ICANN, or anyone else, issue a modification/clarification.
> 
> d/
> 
> -- 
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf