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

Miles Fidelman <mfidelman@meetinghouse.net> Sun, 09 November 2014 16:25 UTC

Return-Path: <mfidelman@meetinghouse.net>
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 4300E1A1B1B for <ianaplan@ietfa.amsl.com>; Sun, 9 Nov 2014 08:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.881
X-Spam-Level:
X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 mxasQwLDQSKL for <ianaplan@ietfa.amsl.com>; Sun, 9 Nov 2014 08:25:14 -0800 (PST)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id B67E11A1B1A for <ianaplan@ietf.org>; Sun, 9 Nov 2014 08:25:14 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id AB3A8CC080 for <ianaplan@ietf.org>; Sun, 9 Nov 2014 11:25:13 -0500 (EST)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net
Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kozpzQUsnfPP for <ianaplan@ietf.org>; Sun, 9 Nov 2014 11:25:08 -0500 (EST)
Received: from new-host-3.home (pool-72-93-213-216.bstnma.fios.verizon.net [72.93.213.216]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 39555CC085 for <ianaplan@ietf.org>; Sun, 9 Nov 2014 11:25:01 -0500 (EST)
Message-ID: <545F955C.5040405@meetinghouse.net>
Date: Sun, 09 Nov 2014 11:25:00 -0500
From: Miles Fidelman <mfidelman@meetinghouse.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
MIME-Version: 1.0
CC: "ianaplan@ietf.org" <ianaplan@ietf.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> <D083864D.138D18%jon.peterson@neustar.biz> <A6D94EF5-BD92-4080-8C18-E415BD0BB880@isi.edu> <C78A1523-316F-46A1-9FCE-D0D205679C84@gmail.com> <13B26DE5-315D-453F-B89B-377CCD338ED9@isi.edu> <A7BD5ECF-11E4-42F1-A2B7-BF9B399635C3@gmail.com> <14D42443-53E7-49FA-88DD-7F4BB6BC2DF4@istaff.org> <545F69FB.5000501@meetinghouse.net> <7B719509-5A93-4B85-B7E2-262DDCB64461@istaff.org>
In-Reply-To: <7B719509-5A93-4B85-B7E2-262DDCB64461@istaff.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/dSFKVbbDs0MQDKr8uPRzK7WRLRI
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: Sun, 09 Nov 2014 16:25:16 -0000

John Curran wrote:
> On Nov 9, 2014, at 3:19 AM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
>> John Curran wrote:
>>> It is not at all clear whether the IETF has any need to own the
>>> IANA mark or domain; if the IETF determines that its use of the
>>> mark and domain are important to the protocol parameter function,
>>> then it only needs to ensure that it has the ability to use them -
>>> that does not require ownership, only an appropriate agreement
>>> providing for such use with the owner... (while there may be some
>>> merit in being that owner, that is more than strictly necessary.)
>> The primary reason for addressing the issue is to avoid or reduce the potential for costly trademark litigation down the road.  If all remains cooperative, as may predict, then there's no issue at all. On the other hand, if an edge case arises - an attempt to change IANA contractors under less-than-cooperative situations - there is the potential for nasty litigation, as well as technical game playing.
> Miles -
>   
>    I was probably unclear in my points above - my first point is simply that
>    if the use of the mark and domain name are deemed incidental to the proper
>    functioning of the IETF's protocol parameter registries, then the potential
>    for costly trademark litigation is rather low, as the IETF can always switch
>    to use of some other name if continued use of the IANA name & mark is not
>    possible.
>
>    If use of the IANA mark/name is important to proper functioning of the IETF's
>    protocol parameter registries, then some arrangement should be made so that
>    it is available for this purpose.  My second point was simply that arranging
>    for use of the mark/name does not mean obtaining ownership; it likely can be
>    accomplished with proper licensing regardless of the owner, and discussion
>    (in the case of use of the name/mark being relevant) should be focused on
>    ensuring the IETF has appropriate arrangements, which does not automatically
>    mean requiring ownership of the marks and name.

Agreed.  They are two, separate issues.

Personally, speaking simply as the occasional  consumer of information 
from iana.org, it strikes me that clarity of where information resides 
IS important to the IANA function.  From a slightly wider point of view, 
given that we are talking about the "IANA transition" - it seems that 
the name/mark is inherently associated with the function, and it would 
be a significant change if we were, at some point, to have to change 
that.  ("Continuity of naming" if you will.)

>
>> As a general rule, organizations don't "go into business" with the expectation of unfriendly relations. Contracts are written to create clarity as to roles, and responsibilities, and to attempt to detail, in advance, how edge cases are to be handled.  In the eventuality of things going wrong, the clearer the contract, the less likely things are to end up in costly litigation.
>    Correct, but that refers to the desire for clear arrangements (which I was
>    not arguing) - my point was simply that, should the IETF deem that it has
>    a need in the use of the mark & name, it is not clear that ownership is the
>    only option available.
>    
>

Agreed, again - there are multiple ways this could be done.  My personal 
opinion is that having ownership in the hands of the incumbent 
contractor opens the door for potential difficulties in the future 
(having personally been through the hassles of dealing with domain name 
registration conflicts, following the re-organization of several 
different non-profits).

At the very least, I'd like to see something in our proposal that says 
that this is an issue that has to be addressed clearly as part of final 
transition arrangements.  I'd personally like to see the IETF lawyers 
weigh in and suggest a proposed approach to put forward to the ICG (when 
flagging a problem, it's always nice to be able to offer a solution).

Miles

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra