Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

John Curran <jcurran@istaff.org> Sat, 08 November 2014 19:01 UTC

Return-Path: <jcurran@istaff.org>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26C1A6FD2 for <ianaplan@ietfa.amsl.com>; Sat, 8 Nov 2014 11:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRk_-UkZkQhy for <ianaplan@ietfa.amsl.com>; Sat, 8 Nov 2014 11:01:56 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE891A6FD0 for <ianaplan@ietf.org>; Sat, 8 Nov 2014 11:01:56 -0800 (PST)
Received: from [64.129.1.11] (helo=[172.20.3.176]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1XnBGl-000J0b-KF; Sat, 08 Nov 2014 19:01:55 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 64.129.1.11
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+MW23SQz+BOoSmE2bby3rP
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: John Curran <jcurran@istaff.org>
In-Reply-To: <20141108155153.GB37292@mx1.yitter.info>
Date: Sat, 08 Nov 2014 11:01:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3455F9E-5B69-4597-955F-1AF8331C3279@istaff.org>
References: <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <D0805C27.136BE7%jon.peterson@neustar.biz> <059f2b06a7b44f09b7568d8966861fb8@EX13-MBX-13.ad.syr.edu> <D0824FAD.137A42%jon.peterson@neustar.biz> <E314302D-5179-4899-9DB7-A3AF18C134E8@gmail.com> <20141108155153.GB37292@mx1.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/D-HU0JBrsxP9t_MmZZ7K0fhmk6I
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Nov 2014 19:01:59 -0000

On Nov 8, 2014, at 7:51 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> ...
> Wait, no.  I deny this premise for the purposes of this discussion.
> 
> We _already_ have in the draft a term that says "iana.org goes with
> the operator."  This is, AIUI, a request for a term that is already in
> effect.
> 
> What we are talking about is a case where different registries go
> their separate ways, and they do so un-co-operatively.

Andrew - 

I concur with the former part of the statement (we are talking about the
case where different registries go their separate ways), but not the latter 
(they do so uncooperatively)

I can think of several potential reasons why one of the communities might 
want a different IANA operator than the others, and believe that such could 
happen under circumstances of cooperation, _particularly_ if appropriate 
attention is paid to the issue up front.

Suppose, for example, that the IETF finds it desirable to move to an IANA 
operator in a different legal jurisdiction at some point in the future. 
Such a choice should not get entangled in numerous unknowns around use 
of the IANA mark or domain name; i.e. it should be understood in advance 
whether the IETF (or its subcontractor) will have the ability to make 
use of these so that the discussion regarding any such change can be 
well-informed.

> In that case, _by definition_, iana.org won't affect all communities
> (or anyway, can't affect them all in the same way).  
> 
> By definition, it can't be handled co-operatively in this case, because
> we're already into non-co-operation as part of the scenario we're trying
> to cope with.

Incorrect, as you correlate the need for a change with lack of cooperation -
the need for a change may be driven entirely by changes in the IETF's own
situation or requirements, not imply any lack of cooperation among other
parties.  Such cooperation exists today, and I personally believe should
be discussed and formalized, as there is the risk that failure to directly 
address such regarding the use of the mark and domain name could result in
arrangements that make any future changes contemplated by the IETF rather
problematic.

Given that the ICG RFP explicits requests identification of independencies, 
it would be remiss for the IETF to omit discussion of their use of the mark 
and domain unless it is the IETF community's view that their use is simply 
happenstance and their ongoing use (or lack thereof) is completely incidental 
to the proper functioning of the IETF's protocol parameter registries.  I have 
heard several folks express that view (yourself, Brian, Jon), do you believe 
there is rough consensus within the WG (and greater IETF) on that position?  

I would be fine with no discussion of arrangements for the use of the mark 
or domain name if a statement to this effect (their use is incidental to the 
proper functioning of the IETF's protocol parameter registries and hence no 
arrangements are needed) were instead placed in the document.

/John

Disclaimer: my views alone.