Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion

From: Richard Hill <[email-masked]>
Date: Tue, 07 Oct 2014 21:58:45 +0200

Ok. So my proposal would be to transfer to the IETF Trust. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: Brian E Carpenter <[email-masked]> </div><div>Date:07/10/2014  21:49  (GMT+01:00) </div><div>To: [email-masked] </div><div>Cc: Eliot Lear <[email-masked]>,[email-masked] </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator change
  and avoiding confusion </div><div>
</div>On 08/10/2014 00:32, Richard Hill wrote:
...

> As part of the transition agreement, ICANN could agree to transfer the domain name to ISOC (which is the legal entity for the IETF), with the understanding that this is a sort of "escrow" agreement, and that ISOC will use the domain name only to provide the IANA function as agreed by the customers of the IANA function, in particular the IETF.

No. The legal entity for this purpose is the IETF Trust, whose specific
reason for existence is to own intellectual property on behalf of
the IETF. When the Trust was created, ISOC (and CNRI) transferred all
their relevant IPR to the Trust, but we refrained from tackling the
ICANN IPR issue at that time.

You can see the original Trust Agreement at http://trustee.ietf.org/trust-agreement.html

   Brian

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 09:07:18 +0200

Agreed. This could be part of the IETF response to the ICG and it would then have to be reconciled with the other responses, unless they come up with the same idea. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: manning bill <[email-masked]> </div><div>Date:08/10/2014  08:05  (GMT+01:00) </div><div>To: Richard Hill <[email-masked]> </div><div>Cc: [email-masked],Alissa Cooper <[email-masked]>,Eliot Lear <[email-masked]> </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
  change and avoiding confusion </div><div>
</div>presuming, of course, that the other groups affected by the IANA transition (the addressing community and the dns registry/naming community) have no problems
with the IETF trust (the protocol bits)  holding the IANA public presence…

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 7October2014Tuesday, at 22:12, Richard Hill <[email-masked]> wrote:

> I agree with Eliot. And I still think that it would be better if IANA.ORG were transferred to the IETF Trust. 
> 
> Best Richard
> 
> On October 8, 2014 6:31:56 AM CEST, Eliot Lear <[email-masked]> wrote:
> Hi Alissa,
> 
> On 10/8/14, 12:59 AM, Alissa Cooper wrote:
>> Hi Eliot,
>> 
>> On Oct 7, 2014, at 1:45 PM, Eliot Lear <[email-masked]> wrote:
>> 
>>> People use what documentation they have– some of it hardcoded.  Ours is in effect hardcoded.  We are not going to update all of those RFCs with new ones
>> 
>> Why not? I mean, why would we take off the table our ability to do a global search-and-replace on the domain name?
> 
> Because the suggestion that we would is beyond the pale, and it doesn't solve the problem.  RFCs are meant to be entirely stable.  They are widely distributed.  They have been translated into different languages.  They have been incorporated into other documentation, including books.  And even if we did change them, we CAN'T change other peoples' documentation.
> 
>> 
>>>> With all of that said, if what we were actually talking about on the call (as opposed to what I thought we were talking about) was putting some language in the SLA that says that in the event of the need for either party to host the parameters somewhere besides iana.org, both parties will work together to minimize confusion on the part of iana.org visitors, I see no problem with that.
>>> 
>>> That is pretty much what I had in mind.  Details to be worked out by the IAOC and ICANN in a supplemental agreement.
>> 
>> Good. As long as this is a request to the IAOC about avoidance of confusion related to iana.org, and not the location of the authoritative registries, I think we are in agreement.
>> 
> 
> To be clear: it must be clear to all where we think our authoritative registry is, and ICANN must make that clear as well on IANA.ORG   That is what is necessary.
> 
> Eliot
> 
> 
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

_______________________________________________
Ianaplan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 21:27:41 +0200

I agree with what John says below. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: John Curran <[email-masked]> </div><div>Date:08/10/2014  15:25  (GMT+01:00) </div><div>To: manning bill <[email-masked]> </div><div>Cc: "Martin J. Dürst" <[email-masked]>,[email-masked],Richard Hill <[email-masked]>,Alissa Cooper <[email-masked]>,Eliot Lear <[email-masked]> </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion </div><div>
</div>On Oct 8, 2014, at 7:57 AM, manning bill <[email-masked]> wrote:

> On 8October2014Wednesday, at 2:21, Martin J. Dürst <[email-masked]> wrote:
> 
>> On 2014/10/08 15:05, manning bill wrote:
>>> presuming, of course, that the other groups affected by the IANA transition (the addressing community and the dns registry/naming community) have no problems
>> Of course. I think this may depend on how it is proposed. It's not that the IETF wants exclusive control, but that the IETF Trust is already established for such cases, and such a solution would provide an additional element of "checks and balances" and additional stability for everybody. Setting up another organization would lead to a lot of useless overhead.
>> 
>> Regards,   Martin.
> 
> Of course these other communities also, already have (and in some cases with a longer history than the IETF trust) such vehicles to handle such cases (the NRO comes to mind).  The IETF is not special, unique, or privileged over these other groups.  The have equal  interest/standing and (imho) should not be dismissed out of hand when considering the fate of IANA.ORG.   It should not be considered a done deal that the IETF trust is the proper home for this site.  Again, imho.   I have no standing and no vested interest in any particular community.

mumble... (general expression indicating that I'm somewhat at a loss 
for words for how to appropriately phrase a coherent response)

Short answer: I think Martin has it correct - the IETF providing a 
specific approach for handling such an issue is not a declaration of 
any form of control, but simply the recognition that there should be 
clarity in this area and offering one possible proposal for doing so.

Given the variety of the communities involved, it is quite likely that 
proposals to the ICG will have quite a diversity in identified issues 
and corresponding mechanisms for addressing each...  All of them will 
need to be considered simply for what they are, i.e. _proposals_, not 
declarations of territory/authority/control, not "a done deal", etc.

It is crucial that each communities views are fully included in their 
ICG proposals, as it will be in reviewing these proposals that the 
material issues (overall alignment/differences in approach) will be 
identified.

/John

Disclaimer: my views alone.

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 21:30:12 +0200

My understanding is the same as Marc's below. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: Marc Blanchet <[email-masked]> </div><div>Date:08/10/2014  15:48  (GMT+01:00) </div><div>To: Andrew Sullivan <[email-masked]> </div><div>Cc: [email-masked] </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
  change and avoiding confusion </div><div>
</div>Le 2014-10-08 à 09:33, Andrew Sullivan <[email-masked]> a écrit :

> On Wed, Oct 08, 2014 at 09:25:18AM -0400, John Curran wrote:
>> 
> Doesn't that just kick the can down the road?  The ICG is supposed to
> give NTIA one proposal, not a menu, I though?  So these various ways
> of handling the issue would need eventually to be reconciled in any
> final proposal, wouldn't they?  And since the ICG isn't supposed to be
> making decisions, at that point wouldn't this all have to go back
> through community processes?

I understand the process as ICG is "coordination". My interpretation of this is that if there are multiple/different proposals/views on a specific topic, they would have to discuss with the communities to try to reach concensus on something _and then_ come back to the communities to confirm concensus. ICG not deciding. That is my definition of a coordination body, well, at least an active one, instead of a passive collecting documents.  

Marc.

> A
> Andrew Sullivan
> [email-masked]

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 21:30:54 +0200

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: John Curran <[email-masked]> </div><div>Date:08/10/2014  15:50  (GMT+01:00) </div><div>To: Andrew Sullivan <[email-masked]> </div><div>Cc: [email-masked] </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
  change and avoiding confusion </div><div>
</div>On Oct 8, 2014, at 8:12 AM, Andrew Sullivan <[email-masked]> wrote:

> ... If, on the other hand, the termination came into
> effect under disputatious circumstances, then the very nature of the
> dispute would almost certainly turn on the correct actions with
> respect to the registry.  (If the IETF had another reason, it seems to
> me that it would be an indication that the IETF had gone off the
> rails, and in that case it would be by no means obvious that the
> registry _should_ move, in so far as the good of the Internet is
> concerned.)  In that case, it's hard to imagine a way in which the
> to-be-terminated operator could plausibly take down the published
> registry under dispute, and still maintain their claim.  So there'd be
> a dispute anyway, and it would be public and harmful regardless of
> what the contract says.
> 
> I think it is a point of prudence that you never negotiate over
> something where the outcome makes no difference. 
> ...

Andrew - 

Does the IETF have any duty to the community to provide the registry data 
to the public in a clear and unambiguous manner?  I expect that some of 
the protocol-using community would not appreciate two conflicting registry 
instances (both asserting to be the correct one) operating for very long...   

One benefit of a termination clause for such a situation is that the IETF 
could have a basis for seeking prompt legal resolution during a dispute,
and this might not be readily available unless data handling post-termination 
has already be established in any agreement.  (Of course, this also presumes 
that the IETF isn't the one gone "off the rails", thus highlighting why these
IANA Stewardship discussions have governance and accountability aspects that
go beyond simply the routine supervision of IANA's registry administration.)

/John

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 21:31:43 +0200

Once again,  I agree with what John says below. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: John Curran <[email-masked]> </div><div>Date:08/10/2014  15:58  (GMT+01:00) </div><div>To: Andrew Sullivan <[email-masked]> </div><div>Cc: [email-masked] </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
  change and avoiding confusion </div><div>

> through community processes?

It may very well lead to such, but that's not "kicking the can down the
road", since what comes back should actually contain both the IETF's view 
as well as any other communities countervailing views on the issue, and 
the IETF can then decide how to proceed in light of that feedback.

Think of it sort of like an "IESG review", only done on a larger scale...

:-)
/John

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 21:33:44 +0200

Sorry to be repetitive,  but I once again agree with John. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: John Curran <[email-masked]> </div><div>Date:08/10/2014  16:53  (GMT+01:00) </div><div>To: Andrew Sullivan <[email-masked]> </div><div>Cc: [email-masked] </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
  change and avoiding confusion </div><div>
</div>On Oct 8, 2014, at 10:22 AM, Andrew Sullivan <[email-masked]> wrote:

> On Wed, Oct 08, 2014 at 09:50:18AM -0400, John Curran wrote:
>> 
>> to the public in a clear and unambiguous manner? 
> 
> To the extent the IETF is able to do that, yes.  But _ex hypothesi_,
> we're talking about a case where the right thing to do for the
> registry is what's under disagreement.  And just as the IETF doesn't
> prevent (for instance) faq.org from republishing the RFCs, I sincerely
> hope we're not trying to suggest that the protocol parameters are
> supposed to be under IETF control.  Indeed, the proposal that the data
> all be put in the public domain by definition will give anyone
> permission to publish it.

"to publish it", or to _accurately/faithfully_ publish it?  If I chose to 
publish the RFC series on numerous websites (RFCs.[newgTLD], bestRFCs.foo, 
etc.), I don't think the IETF should have a problem with my doing so, but 
if I choose to publish RFCs with minor changes sprinkled throughout, that 
is a different matter, no?

> What people really are asking for here is a promise that others won't
> compete.

I would disagree; it's not a question of competition; it is about whether
the IETF has any position on IANA data integrity...

> For cases where they're all acknowledging the IETF's
> correctness, that's not going to be a question.  So the only case
> we're taking about is where someone else is claiming that the IETF has
> somehow lost legitimacy as the source of the registry data, and that
> therefore an alternative data source is needed.  

Not correct.  While that may be the expected case, it could also be simply
a commercial dispute (SLA's, $) that leads to termination.  If the ex-IANA
operator decides to continue to accept registration requests, e.g. for
Private Enterprise Numbers <http://pen.iana.org/pen/PenApplication.page>
and charge for the service, does the IETF care?  Once contracted, does 
that IANA operator have an an eternal franchise on making entries into 
IANA registries, even post-termination?

>> I expect that some of 
> Of course not.  But surely you're not asserting that, if such a
> dispute actually arose, it'd be the sort of thing that would be
> trivially resolved by someone saying, "Oh!  I see!  A contract term!"

Actually, such a contract term could provide crucial for the IETF (and its 
_new_ IANA operator) are able to continue to publish what it feels is the 
correct information.  I do not know the value of this to the IETF community, 
but do recommend its discussion.

> I think you have a different meaning of "prompt" than I do.  In my
> opinion, in a case like this, if we do not have an actual shared
> belief on the Internet about the right data source, then it makes no
> difference what lawyers and judges say because there will continue to
> be controversy.

Yes and no, depending on the reason for termination as noted above...

In disputed terminations, the ability for the IETF to continue to facilitate 
IANA registry administration and publication without interference could easily 
be predicated on the specific termination language that is contracted.

This will do nothing to settle dispute controversy in the community over "the 
right data source", but note that there are many other potential termination 
disputes for which it may be rather important.

/John

---

From: Richard Hill <[email-masked]>
Date: Thu, 09 Oct 2014 07:44:51 +0200

I fully agree with Miles' comment below. 

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: Miles Fidelman <[email-masked]> </div><div>Date:09/10/2014  04:07  (GMT+01:00) </div><div>To:  </div><div>Cc: [email-masked] </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
  change and avoiding confusion </div><div>
</div>Alissa Cooper wrote:
> On Oct 8, 2014, at 12:31 PM, Milton L Mueller <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I agree with Eliot Lears original analysis and proposal. In 
>> particular, I cant accept these arguments:
>> *From:*Ianaplan [mailto:[email-masked]]*On Behalf 
>> Of*Alissa Cooper
>>
>> #4-6 would require some re-education of people on our part so that 
>> they know where to look to find the parameters they need. We may also 
>> need to go back through our documentation and change references 
>> toiana.org <http://iana.org/>to the correct new domain name. From my 
>> perspective, these are operational annoyances, but they are not a big 
>> deal. You found many of the references yourself
>> It is a big deal, or at least big enough to cause some confusion and 
>> so easy to avoid that I fail to understand why anyone would oppose 
>> foreclosing it.
>
>
> I fail to see how negotiating contractual terms with ICANN could be 
> described as easy. I fully expect it to be just the opposite.
>
> From an IETF perspective, implementers choosing to use protocol 
> parameters that are defined elsewhere but that compete or fail to 
> interoperate with the parameters defined in RFCs is a big deal with 
> potentially big implications for the Internet. Implementers being 
> confused for a brief stretch of time about where to find a registry is 
> not.
>

But probably a lot easier to negotiate contractual terms with ICANN 
BEFORE the transition, than after the NTIA contract is no longer a 
lever.  Best to get this stuff done now, rather than kick it down the 
street.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Richard Hill <[email-masked]>
Date: Fri, 10 Oct 2014 13:00:35 +0200

Best Richard

Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: John Curran <[email-masked]> </div><div>Date:10/10/2014  12:55  (GMT+01:00) </div><div>To: Bernard Aboba <[email-masked]> </div><div>Cc: [email-masked],Alissa Cooper <[email-masked]>,"Eliot Lear (elear)" <[email-masked]> </div><div>Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion </div><div>
</div>On Oct 9, 2014, at 10:46 PM, Bernard Aboba <[email-masked]> wrote:

John Curran stated: 

"Presently, the IANA operator is subject to several provisions in the IANA functions contract
which explicitly address transition to a new IANA operator; these include C.7.3 and I.61
(I have attached the relevant text for these provisions below for reference.)"

[BA] Indeed.  Given that ICANN has already filed a transition plan as required under the contract, it seems sensible for me for the appropriate groups (probably the IETF Trust in the case of the IETF) to obtain and examine that plan, with the goal of analyzing it and opining on its usefulness in the situation we now face.   While it highly likely that there are additional corner cases (such as individual functions moving to a new operator) not handled by the filed plan, it represents at least one take on what would be required for a unitary transition.

My assumption is that given the overall good relationship with the Contractor, that the Transition Plan could be obtained merely by asking (possibly with some redactions), assuming that the USG did not get in the way.  While we *could* act as if the plan did not exist and attempt to recreate it from scratch, it's hard for me to imagine why this approach would be preferred.  

I'm not quite as concerned about the details of such a plan, as the obligation that it 
creates for the current IANA operator to _transition_, i.e. to actively cooperate with 
a planned change in the state of affairs from them performing to another doing so.

The important question is whether the IETF (and to some extent the RIRs) feel it is 
desirable to include similar obligations in their IANA contracting; this would provide
contractual assurance that termination (e.g. for SLA reasons) is actually a termination
rather than bifurcation/duplication of IANA registry services, with ensuing confusion
in the community as a result.

Not doing so when contracting would leave open a fairly significant issue for any future 
transition and could easily be argued to be poor stewardship of these functions (i.e. it's 
not often that one is accused of doing a worse job of planning than "the government", 
but it would appear to be apt in this case if not included in IANA operator accountability 
requirements outlined in any IANA stewardship transition plan.)

FYI,
/John

Disclaimer: my views alone