ICANN ICANN Email List Archives

[comments-cwg-naming-transition-01dec14]


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

JPNIC's comment submission for "Cross Community Working Group (CWG) On Naming Related Functions Public Consultation on Draft Transition Proposal"

  • To: comments-cwg-naming-transition-01dec14@xxxxxxxxx
  • Subject: JPNIC's comment submission for "Cross Community Working Group (CWG) On Naming Related Functions Public Consultation on Draft Transition Proposal"
  • From: MAEMURA Akinori <maem@xxxxxxxxx>
  • Date: Tue, 23 Dec 2014 07:05:26 +0900

JPNIC's comment submission for "Cross Community Working Group (CWG) 
On Naming Related Functions Public Consultation on Draft Transition 
Proposal"

JPNIC admires and appreciate the Cross Community Working Group for its
hard and intensive job.  We support all aspects which have been clarified 
in the section 3.1 of the proposal, which are:

 1) The current operational performance of the IANA Naming Function is 
    generally satisfactory
 2) There is no reason to transition the IANA Naming Functions outside 
    of ICANN concurrent with the IANA Stewardship Transition

 3) Not to seek to create another ICANN-like structure

 4) Not to seek to replace the role of the ICANN multistakeholder 
    community with respect to policy development, and

 5) The existing separation between ICANN as a policy body and ICANN as 
    the IANA Fuctions Operator needs to be reinforced and streangthened.

Furthermore, we agree the proposal's approach to list up the existing 
functions within NTIA with regard to IANA Stewardship and replace them 
with a newly set mechanism by the Global Multistakeholder Community in 
order to achieve the minimal change which will be still effective to 
work, and the proposed mechanism should in general be acceptable.

With these said, we have several points of concern as far as we can 
learn from the published proposal, which might be of problem subject 
to the further detail and implementation.


 a) relationship between Contract Co. and MRT

The proposal reads that MRT is not the governing board/entity of Contract 
Co., and in the Webinar on Wednesday 4 December, it was explained in 
order to avoid creating the single point of authority.  However, from 
the stipulation of the section 3.2 regarding MRT, it should be judged 
that MRT will hold the control on the significant decisions of Contract 
Co. to be effectively regarded as the governing board of it.  We don't 
have clear idea how MRT could be separated from Contract Co., with the 
powers on those significant decision held, thus suppose that it would 
be tricky and less stable if it be possible.  It should be carefully 
examined that the separation of Contract Co. and MRT should be feasible 
in a stable way, or even another approach to have MRT as the governing 
board of Concract Co. with sufficient separation of power or check-and-
balance mechanism.


 b) MRT composition in conjunction with CSC

What MRT examines for Contract Co. is the affairs of the IANA function 
operations. It's, by definition, of nothing to do with the policy of 
the resource, but very important in terms of the operations, with which 
the direct stakeholders of the resource, in this case TLD registries, 
are familiar.  Our concern is that it might be slow in the convergence 
of the decision if the MRT has people who are not very familiar with 
the registry operations.  The composition of MRT, the qualification of
the members and power which each member is entitlied are the keys for 
this concern. as well as CSC's power toward MRT's desicion.


 c) Public posting of all IANA change requests

The section 3.4.3.1. reads the proposed public posting of all IANA 
change requests is "as a notification that a change is being made", 
which means the posting is to be made before the change.  It is not 
clear if objections or opinions would be allowed before the concerned 
change, but we suppose they would since that may be the reason for the 
posting in advance.  If they be allowed, it may introduce the unwanted 
latency in the change of records of the root zone file by unqualified 
objections and opinions.  It is notable that IAP as a redress mechanism 
may help minimizing inappropriate changes.  If there should be posting 
in advance with objections or opinions accepted, the detail implementation 
should include effective means to avoid unqualified ones to keep the 
changes in a reasonable process duration.


 d) Independent certification for delegation and redelegation requests

The section 3.4.3.2. stipulates the certification process by Contract 
Co. with an independent counsel for this particular action.  The detail, 
especially clear condition to be certified is key for this function in
order to have an independent counsel act reasonably.  Thus we expect 
the ongoing discussion at CWG on this aspect will consider and develop 
such detail.


 e) Independent Appeals Panel (IAP)

We support the proposal's approach to use existing dispute resolution 
providers, instead of establishing a standing panel.  As a successful 
implementation of UDRP, the key of proper functioning of IAP will be 
achieved by clear provision of the dispute resolution policy and 
favorable engagement of the panelists.  We expect the detailed 
implementation plan will clarify them.

----------------------------------------------------------------------


-----
MAEMURA Akinori   General Manager, Internet Development Dept.
maem@xxxxxxxxx      JPNIC - Japan Network Information Center


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