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

"Richard Hill" <rhill@hill-a.ch> Mon, 03 November 2014 21:53 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 7DD431A8765 for <ianaplan@ietfa.amsl.com>; Mon, 3 Nov 2014 13:53:31 -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 0oM_fHZvVerY for <ianaplan@ietfa.amsl.com>; Mon, 3 Nov 2014 13:53:28 -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 2B9D11A875D for <ianaplan@ietf.org>; Mon, 3 Nov 2014 13:53: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 sA3LrNrg019098; Mon, 3 Nov 2014 22:53:24 +0100
From: Richard Hill <rhill@hill-a.ch>
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ianaplan@ietf.org
Date: Mon, 03 Nov 2014 22:54:05 +0100
Message-ID: <GLEAIDJPBJDOLEICCGMNMENBCNAA.rhill@hill-a.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20141103212831.GF28565@mx1.yitter.info>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/171pKTTBXzsHA8vZwXl1HAA8Qwo
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: Mon, 03 Nov 2014 21:53:31 -0000


> -----Original Message-----
> From: Ianaplan [mailto:ianaplan-bounces@ietf.org]On Behalf Of Andrew
> Sullivan
> Sent: lundi, 3. novembre 2014 22:29
> To: ianaplan@ietf.org
> Subject: [Ianaplan] control and negotiation (was Re:
> draft-ietf-ianaplan-icg-response-02 working group last call)
>
>
> On Mon, Nov 03, 2014 at 09:30:28PM +0100, Richard Hill wrote:
> >
> > Yes.  But we differ on what "staying the same" means.
> >
> > To me, it means that ICANN should not have unfettered control
> of the mark
> > IANA and the domain name IANA.ORG.
>
> So, that's the "different" meaning of "same"?  They have control of
> those items now, and they got it as part of the arrangement that
> created the NTIA agreement in the first place.

Yes. And the question now is what to do, given that NTIA is no longer going
to be involved.

>Stamping our foot
> about moral authority (particularly when it's as dubious as this)
> isn't a strong bargaining position.

As I said before, it's not about bargaining.  ICANN is bound to implement
whatever is in the final proposal that the ICG will transmit to NTIA.

>
> > Exactly.  Trying to negotiate with ICANN if things do fall
> apart is going to
> > be messy.  Anybody who has gone through a divorce, or has
> friends who have
> > gone through divorces, should understand what I'm referring to.
>
> As I've argued repeatedly, in case of separation of the various IANA
> portions from one another, the cases boil down to two: either we have
> a co-operative separation (in which case, there'll be a pointer
> installed immediately to wherever the new registry is), or we have a
> hostile situation (in which case, no amount of agreement in advance
> will help, because everything will be contested and we'll have to act
> much faster than any legal process will permit).

No, if the mark and the domain name are transferred to the IETF Trust now,
then there would be no hostile situation regarding the mark and the domain
name, and no legal actions would be rquired.

>
> If people are genuinely worried about this problem, then the right
> thing to do is not to try to get control of "IANA".  As Alissa keeps
> saying, we still can't split a mark three ways.

That is not correct.  The IETF Trust (or whoever owns the mark) can license
it to one or more entities.

>Therefore, if we are
> really concerned about arranging for that, we should create a separate
> mark and domain name now.

That seems more complicated than transferring the mark to the IETF Trust.

>We should start using the new name instead
> of "IANA" in the newly-minted "Protocol Parameter Registry
> Considerations" section.  We should publish another document that
> says, "IANA now renamed NEWREG for protocol parameters", thereby
> telling everyone that they can read "NEWREG" for "IANA" in all old
> documents wherever a parameter is called out.  And we can point the
> "NEWREG" site to the IANA site (probably by judicious use of a DNAME),
> thereby preserving operation exactly as it currently functions.
>
> Again, I think it is entirely premature and foolish to do that now.
> It would send exactly the wrong message when it is obviously better
> that the various functions stay together and in the incumbent
> operator.  There is effectively zero risk right now that we're going
> to exercise this sort of thing in the short term, so we have lots of
> time to undertake such a strategy in the future should there appear to
> be any chance at all that we might need it.

No.  ICANN is bound to implement whatever is in the ICG proposal.  It is not
bound to implement what might be asked for after that.

>
> > Why do you assume that?  As Milton has pointed out, ICANN is bound to
> > implement whatever the consenus is of the global multi-stakeholder
> > community.
>
> I think Milton is wrong about that.  What incentive does ICANN have to
> accept a term that it doesn't like if the NTIA says it should do it?

Because NTIA may decide not to transition the IANA function.  Or to reopen
the contract and consider awarding the contract for the IANA function to
some other entity or set of entities.

> NTIA has already announced its intention to change things.

Yes, on the basis of "an appropriate transition plan".  And we are crafting
one part of that plan.

>If the
> terms of that change are not to ICANN's liking, then ICANN can do one
> of three things: 1. roll over anyway, 2. hold out and see if NTIA
> blinks, 3. open negotiations with NTIA on extension of the existing
> agreement.  It seems to me that (1) is unlikely

Why?  NTIA asked ICANN to prepare a transtion plan.  In turn, ICANN tasked
the ICG to prepare that plan.  So the plan that will be transmitted by the
ICG will be ICANN's plan.

Why would ICANN turn around and tell NTIA, "no that isn't really our plan,
our plan is slightly different"?  What legitimacy would that have?

> and (3) is not what we
> want.  (2) is unappealing, so we should avoid creating situations that
> could cause that when there's not a significant upside for us.
>
> > Why not keep it simple, and transfer the mark and the domain
> name IANA.ORG
> > to the IETF Trust?
>
> I don't believe that's simple at all.

Why not?  Because ICANN will say no?  As explained above, that doesn't make
sense to me.  But, as I said before, maybe I'm not sufficiently intelligent
to understand.

>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
>