[discuss] Transition scope - a small thought-experiment
Jordan Carter
jordan at internetnz.net.nz
Wed Apr 23 13:52:28 UTC 2014
Hi all
The discussion about what is in or out of scope is a bit abstract, so I
thought I would try and give some short examples that show my concern.
The five wee wee scenarios below only deal with IANA functions operation.
Note that the process currently proposed by ICANN gives the Board the role
of making sure the final proposal remains within the scope and both Scope
and Process are open for comment until 8 May.
These are just some options that come to mind I am not trying to argue in
favour or against any of these.
A) Imagine that the transition plan proposes that IANA remain a functionally
separate part of ICANN as it is now, with no institutional changes.
- that¹s in scope
- it could fly as a proposal
B) Imagine that the transition plan proposes IANA remains within ICANN, but
has an ³IANA Board² - a committee to which IANA staff report and are
accountable to, but that remains within ICANN, uses ICANN corporate services
(ICT systems, offices, payroll, etc etc).
- that¹s in scope
- it could fly as a proposal
C) Imagine the plan proposes IANA become a wholly-owned subsidiary company
of ICANN, with a Board of Directors appointed by the ICANN NomCom process,
but borrowing ICANN corporate services (ICT systems, offices, payroll, etc
etc).
- that's out of scope
- ICANN¹s board would invalidate it as a possible proposal
D) Imagine the plan proposes the IANA functions be split, with some operated
by ICANN (say the protocol registries, the numbering registry) and some
operated by another currently unspecified entity (say the TLD registry).
- that¹s out of scope
- ICANN¹s board would invalidate it as a possible proposal
E) Imagine the plan proposes that IANA be operated by a new entity (e.g. the
IGP model), related to its policy authorities (IETF, RIRs, TLDs, ICANN) by
strong contracts.
- that¹s out of scope
- ICANN¹s board would invalidate it as a proposal
Now.
I firmly believe that all of these options should be on the table, and that
the benefits and costs of different arrays of the IANA functions, different
demands from the IANA customers, different options for protecting the
important IANA function, should be on the table.
And I believe the scope needs to change so that the process we¹re about to
undertake to develop a transition plan keeps ALL options on the table.
I firmly believe that this community has the wit and the will to move
towards a settlement that can work.
I also firmly believe that ICANN would do itself much credit if it argued
the merits of its position in an open process, rather than trying to cut off
options it doesn¹t like before the community has a chance to fully work
through them.
Best,
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140423/d060e7cc/attachment.html>
More information about the discuss
mailing list