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

"Richard Hill" <rhill@hill-a.ch> Tue, 04 November 2014 09:39 UTC

Return-Path: <rhill@hill-a.ch>
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 B39941A8910 for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 01:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 Y2H14oehvqXG for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 01:39:29 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [IPv6:2001:1600:2:5:92b1:1cff:fe01:147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65F31A0030 for <ianaplan@ietf.org>; Tue, 4 Nov 2014 01:39:28 -0800 (PST)
Received: from Laurie (adsl-178-39-117-99.adslplus.ch [178.39.117.99]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id sA49dLrv021863; Tue, 4 Nov 2014 10:39:23 +0100
From: Richard Hill <rhill@hill-a.ch>
To: Alissa Cooper <alissa@cooperw.in>
Date: Tue, 04 Nov 2014 10:39:13 +0100
Message-ID: <GLEAIDJPBJDOLEICCGMNMENFCNAA.rhill@hill-a.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <A7ED5FD7-4DE1-439E-BA28-E5A3F3451B07@cooperw.in>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/ecSpmp9YGAoxyPhS-pKvhF4bQBM
Cc: Marc Blanchet <marc.blanchet@viagenie.ca>, 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
Reply-To: rhill@hill-a.ch
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 09:39:30 -0000


> -----Original Message-----
> From: Alissa Cooper [mailto:alissa@cooperw.in]
> Sent: mardi, 4. novembre 2014 02:24
> To: rhill@hill-a.ch
> Cc: Marc Blanchet; ianaplan@ietf.org
> Subject: control and negotiation (was Re:
> draft-ietf-ianaplan-icg-response-02 working group last call)
>
>
> Hi Richard,
>
> On Nov 1, 2014, at 2:10 AM, Richard Hill <rhill@hill-a.ch> 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.
> >
> > 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.
>
> If the whole point of the above requirement is to increase the
> certainty that transitioning to new operator(s) would be smooth,
> then the fact that the sharing would have to be sorted out
> between the parties severely undercuts the rationale for the
> requirement in the first place.

That's true.  And that's why I now think that the only sensible solution is
to transfer the mark and the domain name to the IETF Trust (or whatever),
with the condition that the IETF Trust make the mark and the domain name
available, free of charge, to whatever entity or entities provide the IANA
function.

>In particular, although none of
> these possible scenarios are very likely, the most likely ones
> all involve ICANN continuing to operate some of the functions,
> IMO. Under that assumption, what you’re saying is that the
> transition plan must require ICANN to transfer its marks and
> identifiers to a subsequent operator, but if the situation arises
> where ICANN were to share the IANA operations responsibilities
> with another operator, then the transition plan is mute on the
> topic and the two operators can work things out any way they
> like. This makes little sense and it strikes me that it puts the
> protocol parameters in a much worse situation than if the current
> contractor is obligated to cooperate with subsequent operators to
> minimize confusion (or ensure backwards compatibility, in Eliot’s
> words). Either of those standards puts the obligation on ICANN to
> achieve the desired outcome, rather than to use a particular
> means which may or may not achieve the desired outcome.

Yes, so see above regarding a simpler solution, and see below for specific
language.

>
> >
> >> 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.
>
> There has been no consensus called on this issue, so I don’t see
> why you would accuse me of “re-opening” an issue that is already
> open.

I was under the impression that some agreement had been reached during the
webcast.  I apologize for misunderstanding. And I certainly had no intention
of "accusing": I think that it is perfectly permissible to reopen issues.

>The amount of list traffic on this topic since Friday
> demonstrates fairly well that the issue is indeed still open and
> ripe for debate.

Indeed.  So here is my proposal for actual language, which would replace the
language currently in draft "02"

"2.  results in the transfer of any associated marks and identifiers to the
IETF Trust, with the understanding that current and subsequent operators of
the IANA function shall be allowed to use them free of charge."

For clarity, the full clause would then read:

"To address concerns regarding appropriate contingencies to transition to
another operator, the IAOC is asked to conclude a supplemental agreement
that-

"1.  maintains the IANA functions operator's obligations established under
C.7.3 and I.61 of the current IANA functions contract between ICANN and the
NTIA [NTIA-Contract];

"and

"2.  results in the transfer of any associated marks and identifiers to the
IETF Trust, with the understanding that current and subsequent operators of
the IANA function shall be allowed to use them free of charge."

Best,
Richard


>
> Alissa
>
>
>
>