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

["Richard Hill" <[e-mail]>]

I think that Eliot's proposal below is excellent.

Best,
Ricard

> -----Original Message-----
> From: Ianaplan [mailto:[e-mail]]On Behalf Of Eliot Lear
> Sent: lundi, 3. novembre 2014 23:03
> To: Andrew Sullivan; [e-mail]
> Subject: Re: [Ianaplan] control and negotiation (was Re:
> draft-ietf-ianaplan-icg-response-02 working group last call)
> 
> 
> 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
> >
> 
> 
>