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

Jefsey <jefsey@jefsey.com> Tue, 04 November 2014 11:54 UTC

Return-Path: <jefsey@jefsey.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 089671A1B0E for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 03:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.069
X-Spam-Level:
X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] 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 NHSFDHGXdPJ7 for <ianaplan@ietfa.amsl.com>; Tue, 4 Nov 2014 03:54:52 -0800 (PST)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (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 497CA1A007F for <ianaplan@ietf.org>; Tue, 4 Nov 2014 03:54:52 -0800 (PST)
Received: from 183.213.130.77.rev.sfr.net ([77.130.213.183]:58504 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from <jefsey@jefsey.com>) id 1XlchH-0007mI-Ci; Tue, 04 Nov 2014 03:54:51 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 04 Nov 2014 12:54:28 +0100
To: Eliot Lear <lear@cisco.com>, Andrew Sullivan <ajs@anvilwalrusden.com>, ianaplan@ietf.org
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <5457FBA7.6050908@cisco.com>
References: <20141103183007.GP27751@mx1.yitter.info> <GLEAIDJPBJDOLEICCGMNEENBCNAA.rhill@hill-a.ch> <20141103212831.GF28565@mx1.yitter.info> <5457FBA7.6050908@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/cGhcSsK7ZA4Yh_ad8vZutvEgwSY
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: Tue, 04 Nov 2014 11:54:54 -0000
X-Message-ID:
Message-ID: <20141104115500.22923.58039.ARCHIVE@ietfa.amsl.com>

Eliot,

if there is blunt transfer this will result from a clash, probably 
pursued by a standing conflict. Who ever is the owner of the name, 
the name will resolve where the root administrator decides. What 
ICANN is building is the ICANN VGN as an heir of the US VGN. I do not 
know how many users will follow them (I suppose, at least initially, 
a very large number). ICANN duties and survival interests will go (1) 
to its users and (2) to whatever may main retain these users.

This is is why they need to stay in control of names and addresses 
which are operational issues. Protocol parameters are of secondary 
interest as they complete protocols which (1) are not changing and 
being implemented every day and (2) can be obtained elsewhere (as 
authorized by RFC 2860).

This means that if the IETF wants to stay as the immutable core of 
the lower layers of the IP technology it is to support the ICANN VGN 
competition, i.e. root operators supporting their own IANA blend 
(names, addresses from RIRs and ITU, parameters from the various 
packet switeched technologies supported by the various ISPs). unless 
the target is to fragment the digital ecosystem use.

I advise everyone to carefully read the Indian revised motion at PP14 
because this IS what IS going to happen as demanded by States, and 
this is probably a good hint of what the IUsers are going to 
implement. (nb. I use "IS" "ARE" "BE" as we [IUCG] use to do when we 
consider something which is beyond our normative reach).

jfc




At 23:03 03/11/2014, Eliot Lear wrote:

>Hi Andrew,
>
>It seems a good time to review why we are at this point, and what can be
>done.
>
>We are seeking what amounts to backward compatibility - that is, things
>keep going the way they were, even in the face of an IANA operator
>change.  That means, at least to me, that the links that are spread
>hither and yon continue to work.
>
>You have stated that you deem it unreasonable to impose post-contract
>responsibilities on the current contract holder.  Fair enough.
>You and Milton came to what seemed like a reasonable compromise which
>was that the next IANA functions operator be transferred the material.
>Then Alissa suggested there might need to be more than one, and
>therefore, that a mark could not be split three ways.
>
>The fundamental goal is that links continue to work.  I suggest that if
>the IETF/IAB or IETF trust takes control of the name, it do so with the
>understanding that it take responsibility for seeing that backward
>compatibility continue for each customer (names, numbers, protocol
>parameters, in particular) for so long as it is safe to do so.  If
>someone else wants to take control of the name, they should make that
>same promise.
>
>How does that sound to you in principle?
>
>Eliot
>
>On 11/3/14, 1:28 PM, Andrew Sullivan wrote:
> > 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.  Stamping our foot
> > about moral authority (particularly when it's as dubious as this)
> > isn't a strong bargaining position.
> >
> >> 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).
> >
> > 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.  Therefore, if we are
> > really concerned about arranging for that, we should create a separate
> > mark and domain name now.  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.
> >
> >> 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?
> > NTIA has already announced its intention to change things.  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 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.
> >
> > Best regards,
> >
> > A
> >
>
>
>
>
>
>_______________________________________________
>Ianaplan mailing list
>Ianaplan@ietf.org
>https://www.ietf.org/mailman/listinfo/ianaplan