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

"Peterson, Jon" <jon.peterson@neustar.biz> Sun, 09 November 2014 20:31 UTC

Return-Path: <jon.peterson@neustar.biz>
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 4D5621A6F58 for <ianaplan@ietfa.amsl.com>; Sun, 9 Nov 2014 12:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level:
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 QgjAZnlmLeiJ for <ianaplan@ietfa.amsl.com>; Sun, 9 Nov 2014 12:31:35 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED8A1A702A for <ianaplan@ietf.org>; Sun, 9 Nov 2014 12:31:34 -0800 (PST)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sA9KUX7a024046; Sun, 9 Nov 2014 15:31:33 -0500
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1qj7wyrhn9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 09 Nov 2014 15:31:33 -0500
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Sun, 9 Nov 2014 15:31:32 -0500
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: John Curran <jcurran@istaff.org>, Miles Fidelman <mfidelman@meetinghouse.net>
Thread-Topic: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
Thread-Index: AQHP960iQbkZx6Ao80Cv4+wEz5Ij95xPyGuAgAA0/ACAAADXAIAAAw4AgACLogCAACs6gP//uiCAgADC1gCAAAfPgIAACgwAgAAESoD//32igIAAiAgAgAAA6YCAAAWHAIAAKOGAgAASLoCAAErKAIAAeYgAgAAktgCAAAkQAIAAaaqAgAAbPACAAAd4AIAAZEGA//+U/oAAVsNggP//ld8AgAHiDQCAAAQkgP//iACAgAEKfgCAAAg3AIAAOEaAgAAP1ACAACe2AIAAXVqAgAAlo4D//8zXgA==
Date: Sun, 09 Nov 2014 20:31:32 +0000
Message-ID: <D0850842.138E23%jon.peterson@neustar.biz>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [192.168.128.137]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DE5D4938FB1C6040870610A67CB747C9@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7617 signatures=670577
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=3.33066907387547e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.997275880753101 urlsuspect_oldscore=0.997275880753101 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.997275880753101 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411090194
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/aDCnpmIaoLUdOtQdj59QHa7v6Do
Cc: "ianaplan@ietf.org" <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: Sun, 09 Nov 2014 20:31:36 -0000


On 11/9/14, 7:34 AM, "John Curran" <jcurran@istaff.org> wrote:

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

That is my view of the situation. I can understand why people seek clarity
from lawyers, and indeed I can't claim I perfectly understand the legal
circumstances under which we currently use the IANA "mark" in our RFCs (if
it relies on anything beyond the RFC2860 agreement, say). But I see no
realistic contingency in which the IETF would enter into costly trademark
litigation to defend our right to populate a protocol parameter registry.
We would just populate a different registry. So I see no need to take
preemptive steps to secure the mark for ourselves. And then...

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

Explaining our past and present use of the IANA to the ICG, and then
empowering the IAOC to negotiate something that preserves "backward
compatibility" in the event of a transition (as I gather Eliot's language
soon will), should get us a certain way down this path. A license alone
can't cover some contingencies: in some sorts of transitions, licenses
might end up in flux. But if the IAOC believes securing some further
license would help preserve "backward compatibility" here, that'd be fine
with me. Still, if worst comes to worst, we're going to have other
remedies at our disposal than the courts.

Jon Peterson
Neustar, Inc.