RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter br oken- onus should be on WG to fix it)]

"Gray, Eric" <Eric.Gray@marconi.com> Fri, 16 September 2005 15:51 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIUO-00026r-In; Fri, 16 Sep 2005 11:51:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIUM-00025Q-BE for ietf@megatron.ietf.org; Fri, 16 Sep 2005 11:50:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25388 for <ietf@ietf.org>; Fri, 16 Sep 2005 11:50:55 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGIZM-0001j3-I5 for ietf@ietf.org; Fri, 16 Sep 2005 11:56:10 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j8GFnaB6005392; Fri, 16 Sep 2005 11:49:36 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14794; Fri, 16 Sep 2005 11:49:36 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id <R3MH2KS3>; Fri, 16 Sep 2005 12:49:35 -0300
Message-ID: <313680C9A886D511A06000204840E1CF0C885E7E@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" <Eric.Gray@marconi.com>
To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, Brian E Carpenter <brc@zurich.ibm.com>, Michael Thomas <mat@cisco.com>
Date: Fri, 16 Sep 2005 12:49:34 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: ietf@ietf.org
Subject: RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter br oken- onus should be on WG to fix it)]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.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://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Philip,

	Apology in advance if this seems to be removed from context,
but your statement (below) seems to have been made generally and is 
not self consistent.  Perhaps you could clarify it somewhat?

--- [ SNIP ] ---
--> 
--> Sure the IETF can pursuade IANA not to register a code point. But if
--> that happens it only makes things worse. There is nothing that can be
--> done to prevent unregistered use and no real disadvantage to doing so as
--> as nobody will want to accept an official registration polluted by prior
--> use.
--> 
--- [ SNIP ] --- 

Generally, the existence of an assignment authority does encourage
its (proper) use - mostly for the reason you state above. Just as 
"nobody will want to accept an official registration polluted by 
prior use", "nobody" (deliberately in quotes) will want to attempt 
to establish an unofficial registration using the approach you've
described.  Doing so is - at the very least - going to adversely
affect popularity and is very likely to result in interference and
potentially even litigation.

Of course the assignment authority has to be credibly recognized 
as the sole assignment authority for this to be true.  IANA is
certainly such an authority.

--
EG

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf