Subject: Re: [Ianaplan] IANA: last call on protocol parameters proposal

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Dec 2014 08:12:18 +0100

Dear Mr. Wilkinson,

Thanks for your comments regarding draft-ietf-ianaplan-icg-response. 
Please find responses below.

> From: LISTS <[email-masked]>
> Date: December 1, 2014 2:24:14 PM EST
> To: [email-masked]
> Cc: Konstantinos Komaitis <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: [IANAxfer] IANA: last call on protocol parameters proposal 
>
> Good evening:
>
> Further to the notice that we have received from ISOC,
> I had already read your draft proposals (Lear and Housley) for which I thank you.
>
> My starting point is that in future there should continue to be a single IANA. IANA, in all its functions,  should be accountable to the multistakeholder Internet community, including users' representatives and governments.
> Although I am formally agnostic as to 'separation' and the eventual creation of a new IANA contractor, for the time being and probably for the foreseeable future, IANA will remain integrated within the ICANN structure.
> Thus, the IETF conclusion to the effect that "No structural changes are required. … " [page 14] is arguably valid.
>
> On the contrary, I gather that CWG ('naming' communities) is coming up with proposals to facilitate structural separation and to create four new entities to control the oversight of IANA. 

Our response is limited in scope to protocol parameters, as indicated at
the beginning.  Naming and numbering may have other requirements. 
However, in response to your point above, and to further make this
clear, I propose that we make the following change:

OLD:

No structural changes are required.

NEW:

No structural changes are required for the handling of protocol parameters.

> Accordingly, the ICG would have work to do to reconcile these divergent proposals. (I have not yet seen a proposal from CRISP).
>
> More generally, I consider that it would be important that the future arrangements for IANA conform to the following criteria:
>
> 1.	IANA services should continue to be free of charge to the final users. (CWG is entertaining a proposal to the effect that the IANA Contractor would collect fees.)

We agree.  RFC 2860 (referenced in the document) makes this clear.

>
> 2.	IANA should remain as a single entity. 
>
> 	This is not so much a question of the interests of the operational communicates ("No structural changes  …"),  but it is rather a matter of the economy of oversight.
> 	All IANA functions, including protocols, numbers and naming, entail significant public interests. Several stakeholders with responsibilities beyond Internet Governance, would not be able to participate effectively in multiple fora, 		including - eventually - several IANA(s).

I believe this is our preference.  However, first and foremost, the IANA
functions operator must perform protocol parameters function to the
satisfaction of the IETF community.  In the unlikely event that this was
not the case, we would have to make a change, regardless of how well the
other functions are being performed.
>
> 3.	Policy and operations should continue to be strictly separated; routine technical management, including that of the Root, should continue to be automatic and automated as much as possible, particularly for the ccTLDs. 
> 	Policy development should continue to be based on participation by all stakeholders at global and local level.

The IETF agrees, and this is documented in RFC 6220, which is referenced
in our response.
>
> I trust that these comments and suggestions are helpful

Yes, thank you very much.

Regards,

Eliot Lear

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 4 Dec 2014 08:29:37 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 4 Dec 2014 08:12, "Eliot Lear" <[email-masked]> wrote:
> >       This is not so much a question of the interests of the
operational communicates ("No structural changes  …"),  but it is rather a
matter of the economy of oversight.
> >       All IANA functions, including protocols, numbers and naming,
entail significant public interests. Several stakeholders with
responsibilities beyond Internet Governance, would not be able to
participate effectively in multiple fora,                 including -
eventually - several IANA(s).
>
> I believe this is our preference.

Wouldn't it be in order to then reflect this preference in the proposal?
Something in the line of:

The IETF would going forward would like to see IANA maintained as a single
entity....( However, the IANA
functions operator must perform protocol parameters function to the
satisfaction of the IETF community.  In the unlikely event that this was
not the case, we would have to make a change, regardless of how well the
other functions are being performed. )

Regards

However, first and foremost, the IANA

> > 3.    Policy and operations should continue to be strictly separated;
routine technical management, including that of the Root, should continue
to be automatic and automated as much as possible, particularly for the
ccTLDs.
> >       Policy development should continue to be based on participation
by all stakeholders at global and local level.
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 4 Dec 2014 08:41:14 +0100

> On 4 Dec 2014, at 08:12, Eliot Lear <[email-masked]> wrote:
> 

I think it is a good goal to have all IANA functions (whatever that is) at one entity, but I think the goal should be to have one primary (default) entity that manage the parameters. IETF/IAB must be able to choose some other provider if there are reasons to do so, like when the management of e164.arpa registry was requested to be taken care of by RIPE NCC and not the IANA function at ICANN. Just like the fact that the IANA Functions Operator must be able to manage parameters requested by others than IETF (like ICANN -- which in fact is the case today).

So yes, primary or whatever, but not only one. There is not only one.

   Patrik

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 4 Dec 2014 14:24:34 +0000

> -----Original Message-----
> 
> OLD:
> 

I would support this change. 

> participate effectively in multiple fora, including - eventually -
> several IANA(s).

I think this comment illustrates a confusion between the policy making activities (which should be open to public participation) and the IANA implementation of policies. To put it bluntly, the IANA is not a "forum." 

I wish to point out that the phrase "stakeholders with responsibilities beyond Internet governance" is in the naming community a code word for "Governments." So when Mr. Wilkinson speaks of "stakeholders with responsibilities beyond Internet governance participating effectively" in these "fora" he is coming dangerously close to articulating a rationale that has been put forward by certain people in the European Commission and the ICANN GAC that oversight of IANA should be used as a choke point for vetoing or altering DNS policies approved by the bottom up process. I think those kinds of pressures need to be clearly identified as such, and clearly rebuffed.

> I believe this is our preference.  However, first and foremost, the IANA

I hope you mean that it is your preference that the IANA functions be combined in a single operator. I hope you can make it clear that it is _not_ your preference that IANA functions are a "forum" in which "stakeholders with responsibilities beyond Internet governance" need to "participate effectively."

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Dec 2014 15:37:01 +0100

Hi Milton,

> I think this comment illustrates a confusion between the policy making activities (which should be open to public participation) and the IANA implementation of policies. To put it bluntly, the IANA…

Yes.  I was referring to Mr. Wilkinsen's heading that "IANA should
remain as a single entity."

For clarity, I believe our preference is that IANA functions contract
for protocol parameters should, on the whole (modulo Patrik's point,
which is quite valid), remain with a single operator.  But above all,
the IANA functions operator must perform satisfactorily for protocol
parameters.  Were that not the case, then (presumably our successors)
would let a new contract to someone else.

> I hope you mean that it is your preference that the IANA functions be combined in a single operator. I hope you can make it clear that it is _not_ your preference that IANA functions are a "forum"…
I am not proposing any change to the text on this point.  I believe it
is already well covered in our response that either party has the option
to terminate our arrangement with six months notice, as specified in the
MoU.  Sorry for any confusion.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 4 Dec 2014 15:40:33 +0100

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
> Sent: jeudi, 4. décembre 2014 15:37
> To: Milton L Mueller; [email-masked]'
> Cc: [email-masked]'
> Subject: Re: [Ianaplan] IANA: last call on protocol parameters proposal
> 
> 
> Hi Milton,
> 

SNIP
> for protocol parameters

I think that you mean "MoU for protocol parameters" and not "contract for protocol parameters".

SNIP

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Dec 2014 11:48:41 +0200

FWIW, I agree with Milton’s take on this. (And Eliot’s suggested changes.)

Jari