comments by Afnic on CWG draft proposal

[Pierre Bonis <pierre.bonis@xxxxxxxx>]

Afnic welcomes the naming related functions draft transition proposal to
NTIA’s oversight of the IANA functions published by the CWG, and want to
commend its members and supporting staff for the impressive amount of work
and their dedication.



The published proposal, as recalled by the CWG itself, :

-          Is not yet complete (last sections will depend on the sections
currently opened to discussion)

-          Covers only the naming IANA function of the multistakeholder
proposal for the IANA transition

-          Is highly dependent or interdependent with the work currently
underway on the ICANN accountability,



Afnic is concerned by the actual complexity of the proposal, given the
fact it’s not covering all the aspects that need to be dealt with before
the final submission.



As we move forward, Afnic would like to call for a simplification of the
proposal, by narrowing the roles of each of the bodies created to replace
the role of the NTIA.



To be more specific :



1/ On the structural or functional separation between IANA and ICANN.



Once recalled than the policy making of the rules that have to be followed
by IANA must be distinct from this body, the need for a very clear
separation between IANA and the policy making body is obvious.



We feel that the structural separation from ICANN is not enough envisaged
in this document, as it could be a powerful simplifier of the proposal. In
any case, the choice between functional and structural separation has
tremendous consequences on the ICANN accountability work currently
underway, and as such, the two options should be clearly and equally put
on the table to allow a risk assessment of the two solutions.



2/ On the proposed structure ( i.e. the new bodies proposed).



-          CSC : all direct customers of the IANA naming function should
be represented, and only them. These customers (essentially CCTLDS and
GTLDS) are already liable to other parties for their own and final SLAs,
that depend heavily on IANA performance. There is no need to expend the
composition of this committee to indirect customers. Furthermore, having
indirect customers within this committee would make harder to distinguish
it from other bodies, such as the MRT, creating confusion and possible
overlaps between the various bodies. In particular, the CSC’s role should
be focused on setting the technical SLA’s with the contractant and
reviewing the IANA technical performance.



-          MRT : We see the MRT as the heart of the proposal, and view
this body as the true steward of the multistakeholder approach. Therefore,
this body should be focused on organizing the multistakeholder open
consultations rather than “representing” the various stakeholders.  In
order to do so, and to be fully in position to draft contracting
decisions, this body must be adequately funded and staffed. And once again
focus on drafting contracting decisions after extensive consultations, as
the review of technical performance should lies with the CSC. Any decision
made by the MRT when it comes to reassigning the IANA naming function
should be decided, not only by the MRT, but proposed by the MRT to the
direct customers and other parts of the community. This mechanism still
have to be described.



-          On the independent certification on delegation and redelegation
requests, as well as the independent review panel, the proposal should
state more clearly that only the way IANA followed the specific policy
should be checked, and in no case or no circumstance should the panel take
a biding decision that is not exclusively and only based on these specific
policies IANA have and will continue to have to follow. In other words,
only IANA’s fulfillment of its due diligences regarding the policies
agreed are to be checked, and in no circumstance the proposed delegation
or redelegation “per se”.



3/ On the relations between IANA and the Root Zone maintainer (RZM).

Unless there is a thorough analysis of the root zone publisher function,
especially by what mechanisms it is bound to publish IANA-approved changes
to the root zone, Afnic believes no responsibility given whether to the
MRT or to contract Co. or even to IANA operator itself could be fully
fulfilled.



The root zone publisher has to remain committed to publish changes in the
root when, and only when, they are approved by the IANA Operator, and
that, in Afnic’s views, should be clearly stated in the transition
proposal.



The proposal should therefore choose between three options, in our views :



status quo (RZM contracts with NTIA)

Contract Co. contracts with RZM
IANA Operator contracts with RZM



In any case, any change approved and asked by the IANA operator to be
implemented after full review should be implemented by the RZM, and this
should be included in any new contract passed with the RZM. It seems to us
this should be stated in the proposal, in order to secure the overall
naming function transition.



Best regards,



Pierre Bonis

 <http://www.afnic.fr/> AFNIC

 <mailto:pierre.bonis@xxxxxxxx> Pierre BONIS
Directeur Général Adjoint
Deputy Chief Executive Officer

 <mailto:pierre.bonis@xxxxxxxx> pierre.bonis@xxxxxxxx
Tél +33 (0) 1 39 30 83 05
Fax +33 (0) 1 39 30 83 01
Twitter / @pierrebonis

1 rue Stephenson

78181
Saint Quentin en Yvelines Cedex
France

 <http://www.afnic.fr/> www.afnic.fr

 <http://www.facebook.com/afnic.fr> Facebook
<http://www.twitter.com/afnic> Twitter