ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Response to CWG proposal

  • To: comments-cwg-naming-transition-01dec14@xxxxxxxxx
  • Subject: Response to CWG proposal
  • From: Kieren McCarthy <kieren@xxxxxxxxxxxxxxxxxx>
  • Date: Fri, 19 Dec 2014 16:03:52 -0800

I have closely followed the naming working group discussions and
contributed to the background sections.

The main piece of feedback I would like to relay is this: the CWG has ended
up proposing an unnecessary, bureaucratic and problematic central body in
the Multistakeholder Review Team (MRT).

I think the IANA functions and the internet in general would be much better
served by a more lightweight, less permanent body.

By making the MRT a persistent entity and by giving it effective controls
over all aspects of the IANA contract, you risk creating a bureaucratic
monster driven more by politics and status than good decisions or effective
technical functioning.

I realize this approach - effectively creating another committee developed
along the lines of ICANN's current stakeholder groups - has become a
default within the ICANN/IANA world. I can also see why it is attractive to
a group formed through the same process.

But the CWG overall has spent far too much time considering the edge cases
and pondering the bigger picture and far too little time understanding what
actually happens within the names aspect of the IANA contract.

There has been little or no effort to talk to the parties about the
day-to-day functioning of the contract, whether IANA staff, Verisign staff
or the NTIA. This is highlighted by the fact that details of the process
the NTIA follows in its administration of the IANA contract only appeared
after this proposal was put out to public comment.

As a result of imaging all possible scenarios, the CWG has developed an
over-engineered proposal that is process-heavy and could prove to be an
unnecessary drag on the actual functioning of the IANA contract.

The proposal is also not very "internety" as it requires the selection of a
small number of representatives who will make key decisions. There is no
reason to believe that this will end up producing a better result since
very few of the functions that it is proposed the MRT will deal with
require considered or in-depth policy review.

In terms of firm recommendations for changes.

* Make the MRT temporary and only cause it to be created upon a specific
event rather than act as a standing body. Break it down immediately

* Allow the proposed Customer Standing Committee (CSC) - the actual users
of the naming functions - to address issues directly with the IANA contract
operator rather than require it to go through the MRT.

* Allow the CSC to decide whether to go to the proposed IAP is there is an
issue that cannot be resolved.

* Allow the CSC to decide whether it is needed to create a (temporary)
incarnation of the MRT to address a specific topic or issue by limited what
the CSC is allowed to do in terms of creating new policies

* Do not require the CSC to develop service levels through the MRT. The MRT
has no inherent knowledge or stake in this process and should stay out of
the way.

* Allow the Contract Co. to ask as the approver of changes through the

* Follow the system used by the NTIA when it last reviewed the IANA
contract: run an open public comment process through the use of open
questions (which could themselves be crowd-sourced). Review and repeat back
community feedback. Put together a proposition based solely on that
feedback and ask for review a second time. In other words, do NOT allow the
MRT to become its own decision-making body; keep its power to an absolute
minimum and make it only the receiver, collator and reflector of community

* Go through all the functions that the MRT is expected to carry out,
identify any that would bring with them some kind of status and figure out
how to hand those functions over to existing bodies.

In short, there is no need to create what would effectively be a new NTIA
for the IANA functions.

The multi-stakeholder element of control can be introduced as and when it
is needed, and only when needed --- when the CSC requests it, or when the
contract is up for renewal.

Thank you for your consideration of my points.

Kieren McCarthy

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy