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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Sat, 01 November 2014 19:58 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 D691B1A0AF1 for <ianaplan@ietfa.amsl.com>; Sat, 1 Nov 2014 12:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.199
X-Spam-Level:
X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 lpeY_lUFQTg9 for <ianaplan@ietfa.amsl.com>; Sat, 1 Nov 2014 12:58:33 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 778641A008F for <ianaplan@ietf.org>; Sat, 1 Nov 2014 12:58:32 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7162932E595; Sun, 2 Nov 2014 04:57:44 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 727c_03a9_a37a93ad_f15c_4232_8810_0800ee19ffc1; Sun, 02 Nov 2014 04:57:44 +0900
Received: from [133.2.249.162] (unknown [133.2.249.162]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E7BE6BF510; Sun, 2 Nov 2014 04:57:42 +0900 (JST)
Message-ID: <54553B34.2000705@it.aoyama.ac.jp>
Date: Sun, 02 Nov 2014 04:57:40 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: rhill@hill-a.ch, Alissa Cooper <alissa@cooperw.in>, Marc Blanchet <marc.blanchet@viagenie.ca>
References: <GLEAIDJPBJDOLEICCGMNEEJICNAA.rhill@hill-a.ch>
In-Reply-To: <GLEAIDJPBJDOLEICCGMNEEJICNAA.rhill@hill-a.ch>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/imLzWzgQW1CFtHpmObEfwsBSzeY
Cc: ianaplan@ietf.org
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: Sat, 01 Nov 2014 19:58:35 -0000

For the record, I read "transfer ... to subsequent operators" as 
transfer in temporal succession. So e.g. transfer to operator A ten 
years down the line, and then to operator B maybe twenty years down the 
line.

Of course it can also be read the way Alissa read it, so it should be 
clarified or changed, maybe along the lines that Richard suggests below.

Regards,   Martin.

On 2014/11/01 18:10, Richard Hill wrote:
> Please see below,
>
> Thanks and best,
> Richard
>
>> -----Original Message-----
>> From: Ianaplan [mailto:ianaplan-bounces@ietf.org]On Behalf Of Alissa
>> Cooper
>> Sent: samedi, 1. novembre 2014 01:12
>> To: Marc Blanchet
>> Cc: ianaplan@ietf.org
>> Subject: Re: [Ianaplan] draft-ietf-ianaplan-icg-response-02 working
>> group last call
>>
>>
>> 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.
>
> Any type of property, including intellectual property such as copyrights and
> trademarks, can be jointly owned by two or more legal entities (physical
> persons and/or legal persons).
>
> Of course the "two operators"  would have to sort out and agree how they
> would share the mark in question, but that is their problem.
>
>> 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?
>
> As mentioned above, the multiple operators would have to agree amongst
> themselves.
>
>> 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.
>
> I don't agree.  It just makes a future transition somewhat more complicated,
> because the "multiple simultaneous operators" would have to agree how to
> handle the situation.
>
>> 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.
>
> You seem to be reopening this issue.
>
> A simple solution, which had been suggested, is that the mark and domain
> name be transferred to the IETF Trust, which surely could be relied upon to
> allow them to be used appropriately by whoever (one or more entities)
> provides the IANA function now or in the future.
>
> I'm OK with Eliot's compromise language in "02".  If people think that that
> results in a situation that is too complex, then I suggest that we adopt the
> simple solution outlined above.
>
> I'd be happy to propose specific language if it is agreed that we do down
> that path.
>
>>
>> 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.
>
> I find that the language in "02" is not as clear and definitive as I would
> have liked it to be, but I'm OK with that language.  But I would likely not
> be OK with anything weaker.
>
>>
>> Alissa