[Chapter-delegates] Update from position zero in the NTIA IANAtransfer of stewardship

[Richard Hill]

Dear Narelle,

Thank you for this.

Please see embedded comments below.

Best,
Richard

>----- Original Message ----- 
>From: Narelle Clark
>To: Chapter Delegates
>Sent: Tuesday, July 15, 2014 4:04 PM
>Subject: [Chapter-delegates] Update from position zero in the NTIA 
>IANAtransfer of stewardship
SNIP

>It was agreed the charter and purpose of the group needs real clarity and 
>agreement and soon.

Indeed.  In my opinion, the charter of this group should be to compile, 
summarize, and present the proposals make to date, and then to call for 
further comment.


>The topic of whether the GAC should get three extra members was briefly 
>discussed.
>It seemed to be the case that there is an argument the GAC should get its 
>five nominees
>on the basis that should any stakeholder group feel strongly 
>disenfranchised

This seems to assume that the coordination group would make substantive 
decisions, which I don't think it should be doing.  Surely 2 per stakeholder 
group is more than adequate if the charter of the group is to summarize 
public discussions.

SNIP


>Reflections for ISOC
>=================
>There is also the timeframe issue: what process do we - ISOC - want to use 
>to consult
>with our members/stakeholders?

I would think so, both through the Chapter Delegates list and the IANAXFER 
list.

>Surely what is needed is this type of process:
>
>Definition phase--> Call for proposals--> Consult & Review proposals --> 
>Recommend

Definition phase was already done by NTIA and ICANN, resulting in a scoping 
document.  But that scoping document has been challenged, and should, in my 
opinion, be revised.  This was commented and discussed in some detail on the 
existing mailing lists.

Call for proposals was already sone, many have been presented on the exising 
mailing lists.

Consult and review proposals is indeed, in my opinion, the next step: the 
coordination group should publish a summary of the discussions and proposals 
that have been submitted to the existing mailing lists.

Recommend is the sticking point.  Who should forumulate that?  It seems to 
me that it should be the broad community, not the Coordination Group or the 
ICANN Board.  In the end NTIA will make the decision, but it should decide 
on the basis of input from the broad community.  If there are some divergent 
views within the broad community, the Coordination Group should present the 
divergent views to NTIA.  The ICANN Board would, at that point, present its 
own views and the NTIA would then be in a good position to make a decision.


SNIP

>In parallel the CG should undertake some risk and governance frameworks to 
>provide some >extra input and checking.

This implies that the Coordination Group would make substantive inputs, 
which explains why the GAC wants more representation.  It may be better if 
the Coordination Group does not make substantive inputs of its own.  That 
is, substantive inputs would come only from the community itself.

>Scope and Charter
>=================
>
>Right now we are in Phase 0 : what is the scope and charter ISOC wants for 
>this group?

See above for my thoughts.

>Does the CG/NISTCG write proposals? Does it make decisions?

Not in my view, except of course to the extent that it summarizes proposals 
made by the community.

>What is in scope, and what is out of scope? For what is out of scope, where 
>do those
>issues go?

The scope includes possible structural separation of the IANA function, 
external accountability for the IANA function, and the relation between 
accountability for the IANA function and accountability for ICANN's other 
functions.

>What is utterly non-negotiable as for scope,

In my opinion, the above.

>and what can be lost?

>I hope we can agree that the essential piece is the ongoing reliable 
>function of IANA
> - the database - in one complete piece

What do you mean by "one complete piece"?  The IANA function comprises the 
maintenance of several unrelated databases, some of which are decentralized. 
In theory, each database could be maintained by a separate organizations. 
That has pros and cons, which should be revisited.

>with a set of operational performance parameters.

I think that the first step is to identify the "owners" of each database. 
Those owners are the most qualified people/organizations to define the 
desired operational performance parameters.

For example, I think most would agree that the IEFF/IAB is the "owner" of 
the protocol parameters database, so it should define the desired 
oeprational performance parameters and, in my view, also decide who should 
maintain and administer that database.

SNIP

>The IAB and IETF have started by putting together some really solid 
>proposals.
>Paul Wilson has written a brilliant piece on the IANA functions:
>http://www.circleid.com/posts/20140713_breaking_it_down_the_iana_transition_in_practical_pieces/

Paul says " I suggest there should be no change in the location of IANA or 
the operation of its functions, "

This implies that the IANA function would continue to be performed by ICANN 
and that ICANN would continue to be subject to US law.  As I've stated on my 
various postings to the existing lists, I do not agree with that.

Paul notes that the MoU between ICANN and the NRO imposes separation of 
functions.  True, but what if a future ICANN Board decides to change that? 
Of course NRO can refuse the changes, but such a situation would create 
confusion and instability.  Better to avoid it by finding a solution such 
that the ICANN Board cannot make such a change, even if a US court order 
attempts to compel it to make such a change.

SNIP

>Proposed Agenda

Maybe you could add something explict about preparing a summary of the 
discussions to date?

SNIP