Comments on CCWG Names draft transition proposal
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 188.8.131.52, 184.108.40.206, and 220.127.116.11 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) 18.104.22.168 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 22.214.171.124. 3) 126.96.36.199 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 ccTLDs 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.