Re: Services and top-level DNS names (was: Re: Update of RFC 2606
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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#_Toc43798015>

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 discussioFrom ietf-bounces at ietf.org Fri Jul 4 14:52:31 2008 
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 621C73A69B9;
	Fri,  4 Jul 2008 14:52:31 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 32DC73A67D9
	for <ietf at core3.amsl.com>; Fri,  4 Jul 2008 14:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 
	tests=[BAYES_00=-2.599]
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 g1ziOuD7mHdg for <ietf at core3.amsl.com>;
	Fri,  4 Jul 2008 14:52:29 -0700 (PDT)
Received: from sbh17.songbird.com (unknown
	[IPv6:2001:470:1:76:0:ffff:4834:7146])
	by core3.amsl.com (Postfix) with ESMTP id BA2F53A69B9
	for <ietf at ietf.org>; Fri,  4 Jul 2008 14:52:28 -0700 (PDT)
Received: from [192.168.0.3] (adsl-68-122-70-168.dsl.pltn13.pacbell.net
	[68.122.70.168]) (authenticated bits=0)
	by sbh17.songbird.com (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: <486E9B98.6040602 at dcrocker.net>
Date: Fri, 04 Jul 2008 14:52:24 -0700
From: Dave Crocker <dhc2 at dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: John Levine <johnl at iecc.com>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
References: <20080704211351.34237.qmail at simone.iecc.com>
In-Reply-To: <20080704211351.34237.qmail at simone.iecc.com>
X-Virus-Scanned: ClamAV 0.92/7639/Fri Jul 4 11:44:12 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(sbh17.songbird.com [72.52.113.17]);
	Fri, 04 Jul 2008 14:52:29 -0700 (PDT)
Cc: ietf at ietf.org
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker at bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at 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#_Toc43798015>

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. n.
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 discussion.
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. 

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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 discussion.
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. 

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.