Comments on CCWG Names draft transition proposal

["Richard Hill" <rhill@xxxxxxxxx>]

I refer to:

  https://www.icann.org/en/system/files/files/cwg-naming-transition-01dec14-
en.pdf

Here are my comments.

Part B
======

1) Sections 2.2.3.4, 2.2.4.4, and 2.2.5.4 state "The jurisdiction for
enforcement of the IANA Functions Contract is the United States."

In the US, there are state laws and courts and federal laws and courts; I
believe that contract law is state law.  I think that these clauses should
be made more precise by specifying which law applies, and which specific
court, by filling in the blanks in the following model:

"The law applicable to the IANA Functions Contract is the law of [FILL IN,
United States of America] and the venue for disputes is the [SPECIFY whether
State or Federal] court of [FILL IN, United States of America]."

2) 2.2.6.4 states "The jurisdiction is set per country and territory."

This is correct, in the same sense that the answer to most legal questions
is "it depends". But it is not particularly informative, because it does not
explain what the jurisdiction might be nor, perhaps more importantly, what
the applicable law might be.

Any dispute between a ccTLD operator and IANA would be a dispute between
ICANN, a US entity, and a non-US entity.  In the absence of a contract
between the ccTLD operator and ICANN, two questions arise: what is the law
applicable to the relation (if any) and what is the jurisdiction in which a
dispute would be heard and, as the case may be, adjudicated.

I think that some legal analysis is required here.

The situation might be simpler if a contract binds the parties, because the
contract might have choice of law and venue clauses.

I see that you provide some examples of that under 2.2.7.1.

3) 2.2.7.4 states "The jurisdiction for enforcement will be as per the
specific agreements."  It would be more precise to say something like:

"The law applicable to the relation and the venue for resolution of disputes
are specified in the agreements."

4) 3.1 says "The existing separation between ICANN as a policy body and
ICANN as the IANA Functions Operator needs to be reinforced and
strengthened."

At present, article I.1 of the ICANN Bylaws implies that ICANN has the
overall responsibility for the coordination and allocation and assignment of
domain names.

I suggest that I.1.1 and I.1.2 of the ICANN Bylaws be modified to read as
follow:

"1. Under contract, coordinates the allocation and assignment of the three
sets of unique identifiers for the Internet, ..."

"2. Under contract, coordinates the operation and evolution of the DNS root
name server system."

5) 3.2 says "The MRT would be a multistakeholder body with formally selected
representatives from all of the relevant communities (exact composition
TBD)."

I presume that "the relevant communities" refers to the "global
multi-stakeholder community", which is broader than the "ICANN community".
So the "relevant communities" would include communities other than the
"communities" that comprise ICANN.

6) 3.2 also describes a CSC.  I don't understand why both a CSC and an MRT
are needed.  Couldn't the CSC perform the functions of the MRT?

And why shouldn't the CSC consist of all users of the names part of the IANA
function, that is all the registries?

The CSC could constitute the membership of "Contract Co.", which could
conveniently be created as a Swiss non-profit association (that is an
extremely light weight structure).

In that structure, the MRT would simply be the board of Contract Co., which
board would be elected by the membership of Contract Co., that is, by the
CSC, that is, by the registries.

This approach would be simpler than the one that is outlined in the draft.
The "global multi-stakeholder community" would be represented by the
registries, which appears adequate to me in terms of the functions that are
under discussion here.

7) 3.3 says "Applicability of local law for the administration by the IANA
Functions Operator of ccTLD’s associated with a specific country or
territory – no changes proposed."

As noted under (2) above, I don't think that it is obvious that local law
would necessarily apply to a dispute between a ccTLD and ICANN.

This section probably needs more work.

8) In the table in 3.4.4:

Under "Subcontracting; [U.S. Presence Requirements]", omit all the bits in
square brackets.

Under "[Functional Separation]", delete the square brackets.

Under "Performance; [Service Levels]", delete the square brackets.

Under ".INT TLD", add a new bullet in the second column: "The contractor
will implement, within a reasonable time, the provisions of ITU-T
Recommendation E.910".

Under "Contractor not authorized to make changes to Root Zone; link to
VeriSign Cooperative Agreement", the response implies that the US government
will continue to be the contracting party for the operation of the
authoritative root server.  Thus, the US government would continue to have a
direct supervisory role regarding a critical function.

It seems to me that a transition of this function should also be proposed.

Under "Intellectual Property", add a new row titled "Trademarks and domain
names".

Column 2 of that row should read "Contractor expressly declares that it
holds the trademark 'IANA' and the domain name 'IANA.ORG' for the purposes
of performing the IANA function and it warrants that it will assign or
license or otherwise authorize the said trademark and domain name to be used
free of charge by any successor entity or entities to which some or all of
the IANA functions may be transferred in the future."

Column 3 of that row should read "H4 and H5".

Also under "Intellectual Property", add a new row titled "Sui generis and
other rights in data and databases".

Column 2 of that row should read "The provisions above regarding patents and
copyrights shall apply by analogy to any sui generis or other rights in data
and databases".

Column 3 of that row should read "H4 and H5 ".

Add a new section "Dispute Resolution".  That section should include a
choice of law and a venue clause, presumably an arbitration clause.

Part C
======

9) In 1, please add the following:

According to the charter of CWG, participants will be able to actively
participate in and attend all CCWG-accountability meetings, work groups and
sub-work groups. However, should there be a need for a consensus call or
decision, such consensus call or decision will be limited to
CWG-Accountability members appointed by the chartering organizations.

One potential participant understood that to mean that "participants" do not
have decision-making rights.  According to that person, in this context, it
is important to note that the NTIA called for the IANA stewardship function
to be transitioned to "the global multistakeholder community", which is
broader than the existing ICANN constituency. In contrast, the CWG, while
stating that it will adhere  to the principle of opennes, has in fact
created a two-tier structure, with decision-making power being restricted to
a specific group of stakeholders, namely those currently involved in the
domain name business.

According to that peson, the CWG process is not a process that is truly open
to the global multistakeholder community.  Consequently, that person did not
participate in the discussions and reserved his right to submit comments to
appropriate forums regarding the outputs of the CWG.