Re: [Ianaplan] draft-ietf-ianaplan-icg-response-02 working group last call

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Tue, 04 November 2014 15:39 UTC

Return-Path: <fluffy@cisco.com>
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 9533D1A037B for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 07:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.495
X-Spam-Level:
X-Spam-Status: No, score=-114.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 P9VPAb7v99h1 for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 07:39:51 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE6C1A8A49 for <ianaplan@ietf.org>; Tue, 4 Nov 2014 07:39:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5715; q=dns/txt; s=iport; t=1415115591; x=1416325191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1o1iG6ApLniYWkOrU6Igss/1mBapCATCKU+a3zp957g=; b=D+spp33H54uYZyiXN7bp2FmUFjlWP+ePEzv+Hr22R5XpkmMh9zRfIDC7 3mQzfBIJMNlENPE3xGTr2X8dfJmUkkx2Xa4CfMu22hT2sGnjI0BpFczt5 KT+K37/Vl7qAUVqIp/iTPpBkZJZBEDTf6o2f3P7at9uvdOJmogy/8KzV5 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkkFAGzyWFStJA2B/2dsb2JhbABcgmsjVFgEzlMKhnlUAoEfFgEBAQEBcguEAgEBAQMBAQEBZAcEBwULAgEIGC4hBgslAgQKBAUJiCMDCQkBDMZsDYYpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF45WggczB4MtgR4FhRwChh6GZIlWghGBMYNMgzKHMIZwg3hsAYFHgQMBAQE
X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="369150898"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 04 Nov 2014 15:39:51 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sA4Fdo5q006375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 15:39:50 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 09:39:50 -0600
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "ianaplan@ietf.org" <ianaplan@ietf.org>
Thread-Topic: [Ianaplan] draft-ietf-ianaplan-icg-response-02 working group last call
Thread-Index: AQHP+EWRfFzysA89nU6DfKZMRWV8dA==
Date: Tue, 04 Nov 2014 15:39:49 +0000
Message-ID: <40696145-F2EA-428B-911D-60AD5988BE43@cisco.com>
References: <6ACE138D-0969-4D8F-9A64-3D1FBB96885A@viagenie.ca> <FC8732DC-BB60-45A2-BF30-0B085CA5FEB9@cooperw.in> <5454B8DE.8040308@cs.tcd.ie> <E5F99046-6C9D-4170-B408-9CA9B7CD6476@gmail.com> <D07CEABF.1357FC%jon.peterson@neustar.biz>
In-Reply-To: <D07CEABF.1357FC%jon.peterson@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B0C62F856196724DB7642A46F5A900C7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/uQfkkNMkscIHRz7eXVi7FoGo75Q
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Alissa Cooper <alissa@cooperw.in>, Jon Peterson <jon.peterson@neustar.biz>, Bernard Aboba <bernard.aboba@gmail.com>
Subject: Re: [Ianaplan] 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: Tue, 04 Nov 2014 15:39:58 -0000

I agree. 


The terms "associated marks and identifiers" seem somewhat under defined but I'd like to make two points about this the text that reads

2.  requires the transfer of any associated marks and identifiers to
      subsequent operators.

A) I don't think we need this 

Yep it would be great if the location where stuff used to be had a pointer to the new location but the protocol registry is largely used by standards people and theses people will know how to find the location of the registry. The only way I can ever find anything in IANA is google. I don't see why we need any trade marks transferred for us to run a parameter registry. If we do need them, we should ask for the right to use them, not ownership. 

B) I think other people will need this more than the IETF does 

I think whoever deals with names is more likely to have a real need for the domain

If people want to transfer these to IETF Trust, great, but I find that possibility pretty unlikely. This is not the hill the we want to die on. We can easily go on without this trademark or domain name. I do not want the important parts of this draft messed up because we got fixated on trying to get something that we do not really need. 

Related to this, I find the phrase "IAOC is asked to conclude a supplemental agreement that ..." weird. Does this mean IAOC has to do this? or that IETF wishes that they try to get that? or what? I have no idea, but one thing I am sure about is that this draft is the wrong place and wrong time to change the relationship between IETF and IAOC. This should be phrased such that it is clear it is within in the normal existing relationship of the IETF and IAOC. 

Cullen


On Nov 3, 2014, at 9:19 AM, Peterson, Jon <jon.peterson@neustar.biz> wrote:

> Agreed. "Cooperation with subsequent operators to minimize confusion"
> gives us enough wiggle-room to be able to manage some likely transition
> situations. The prior language probably doesn't.
> 
> Jon Peterson
> Neustar, Inc.
> 
> On 11/2/14, 7:16 AM, "Bernard Aboba" <bernard.aboba@gmail.com> wrote:
> 
>> I agree as well. 
>> 
>> 
>> 
>>> On Nov 1, 2014, at 3:41 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>>> wrote:
>>> 
>>> 
>>> Alissa's point goes a little beyond my comment on the same
>>> text, but having read this, I share her concerns.
>>> 
>>> S
>>> 
>>>> On 01/11/14 00:11, Alissa Cooper wrote:
>>>> I¹d like to pick up on one comment I made in my last review of the
>>>> document that did not get sufficiently addressed. It concerns this
>>>> text:
>>>> 
>>>> "To address concerns regarding appropriate contingencies to
>>>> transition to another operator, the IAOC is asked to conclude a
>>>> supplemental agreement that- ...
>>>> 
>>>> 2.  requires the transfer of any associated marks and identifiers to
>>>> subsequent operators."
>>>> 
>>>> My problem with this is that one mark cannot be transferred to two
>>>> operators. So if we end up in a situation where there are multiple
>>>> IANA operators for different registries, how will it be decided who
>>>> gets the existing marks? If I were the current owner of such marks, I
>>>> don¹t see how I could agree to this provision without foreclosing the
>>>> possibility that there may be multiple simultaneous operators in the
>>>> future. This is why I think this requirement should be stated as
>>>> requiring ³cooperation with subsequent operators to minimize
>>>> confusion" associated with marks and identifiers, or some similar
>>>> language that provides a safeguard in the event of transition but
>>>> does not mandate specific transfer actions related to marks and
>>>> identifiers.
>>>> 
>>>> I also still find it quite problematic that this section requires the
>>>> IAOC to conclude supplemental agreements, instead of maintaining the
>>>> existing relationship that the IETF has with the IAOC wherein it is
>>>> the IAOC¹s responsibility to determine the format in which is carries
>>>> out its responsibilities on behalf of the IETF.
>>>> 
>>>> Alissa
>>>> 
>>>> On Oct 28, 2014, at 7:42 AM, Marc Blanchet
>>>> <marc.blanchet@viagenie.ca> wrote:
>>>> 
>>>>> Hello, given the proposed timeline agreed during our last interim
>>>>> meeting and based on that the outstanding issues should have been
>>>>> addressed in the -02 version, this message starts a working group
>>>>> last call on draft-ietf-ianaplan-icg-response-02.  This working
>>>>> group last call will end november 11, 23h59 UTC. Given that our
>>>>> meeting is scheduled on november 10th, it would be useful if people
>>>>> send their comments prior to the meeting so they can be addressed
>>>>> or discussed before or during the meeting.
>>>>> 
>>>>> Draft:
>>>>> http://www.ietf.org/id/draft-ietf-ianaplan-icg-response-02.txt
>>>>> 
>>>>> Please send comments to the list.
>>>>> 
>>>>> Regards, Marc&Leslie, co-chairs.
>>>>> _______________________________________________ Ianaplan mailing
>>>>> list Ianaplan@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ianaplan
>>>> 
>>>> _______________________________________________ Ianaplan mailing
>>>> list Ianaplan@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ianaplan
>>> 
>>> _______________________________________________
>>> Ianaplan mailing list
>>> Ianaplan@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ianaplan
>> 
>> _______________________________________________
>> Ianaplan mailing list
>> Ianaplan@ietf.org
>> https://www.ietf.org/mailman/listinfo/ianaplan
> 
>