World Wide Alliance of Top Level Domain-names

ccTLD ICANN Meetings in Marina del Rey

 Home | Meetings | AdCom | ccTLD | Participants 

DATED JULY 25, 2001 (modified by ICANN Sept. 3, 2001)

Deborah Duffy

ICANN agreement/questions October 16, 2001 draft


Note: these questions do not reflect an exhaustive review of potential drafting concerns. Nor do they presume to take into account the possible concerns of other ccTLDs. (The second number in each question refers to the clause in the draft agreement to which the question pertains.)

  1. 1.6 Is there a document dated 1 December 2000 (or is it intended to refer to the IANA report)

  2. 2.10 Is this intended to mean "terminated in accordance with the provisions of this Agreement?"

  3. 3.2 What information is intended by the expression "relevant information"?

  4. 3.3 requires CIRA to "request" change in administrative or technical contact - does this mean that ICANN wishes to exercise a veto over CIRA's choice or does it simply recognize that, as between CIRA and ICANN, only ICANN has the technical means to implement the change?

  5. 3.3 Is there any reason why the change cannot be implemented in five days rather than seven?

  6. 3.3 Is there any reason why the agreement cannot specify the proof that will be acceptable to ICANN? e.g. board resolution certified by secretary of the corporation (under seal if necessary)

  7. 3.3 Is there any reason why the agreement does not specify that ICANN will use these contacts and the reasons for which the contacts will be used?

  8. 3.4 requires CIRA to "request" change in host names or IP addresses of name servers: does this mean that ICANN wishes to exercise a veto over CIRA's choice or does it simply recognize that, as between CIRA and ICANN, only ICANN has the technical means to implement the change?

  9. 3.4 Is there any reason why the change cannot be implemented in five days rather than seven?

  10. 3.4 Is there any reason why the agreement cannot specify the proof that will be acceptable to ICANN? e.g. board resolution certified by secretary of the corporation (under seal if necessary)

  11. 3.4 Should there not be some sort of commitment by ICANN to direct traffic to the nameservers?

  12. 3.4 Do the words "format" and "technical requirements" refer to the request itself or the hostname or IP addresses subject of the request?

  13. 3.4 ICANN is free to request format changes: what kind of changes to format might ICANN wish to make?

  14. 3.4 Can the scope or nature of the changes be identified? If scope of permissible changes cannot be adequately defined or described, can there be a purpose test to define changes?

  15. 3.4 Is there a definition for "nameserver"?

  16. 3.4 What is the "nameserver data" (Can this be defined?)

  17. 3.5 what is "contact information"?

  18. 3.5 As with 3.3 and 3.4: contract must specify what ICANN will accept as proof request is genuine

  19. 3.6 what is the "data" that this is referring to?

  20. 3.6 sentence 2 says data will include "at least" the names etc. Is there more that is required? Desirable? Who will decide what additional data to publish and when?

  21. 3.7 Is "reasonable commercial" intended to be the same as "commercially reasonable"?

  22. 3.7 What is the definition of "DNS resource record"

  23. 3.7 How do you "delegate someone to the nameserver"?

  24. 3.7 Does ICANN get its authority from U.S. DOC? Is the scope of this authority spelled out in the MOU posted on ICANN's website? The clause states "or otherwise": is there another source of this authority? If so, what is it? Are there any relevant restrictions on that authority? Under what circumstances might the authority be withdrawn? If it is withdrawn, must ICANN cease to publish these records? What kind of notice can CIRA expect to receive of the withdrawal?

  25. 3.8 what is "ccTLD deletgations and records" intended to refer to?

  26. 3.9 Can the ccTLD use the old information until it receives the new information?

  27. 3.9 there is no positive obligation on ICANN to give the ccTLDs this information in the first place. Why not?

  28. 3.10 Is intended that the ccTLD be licensed to identify itself as the manager of the ccTLD?

  29. 3.10 Is it intended that the license be assigned with an assignment of the agreement?

  30. 4.1 Why is there not a parallel commitment on ICANN in respect of those nameservers within its control? (Note also need to define "nameserver", "name service", primary and second name servers)

  31. 4.2 Is this referring to subdomains of the ccTLD first level domain? If so, what about the ccTLD subdomains over which the ccTLD does not retain administrative authority?

  32. 4.2 Can the terms "zone file" and "registration data" be defined in the agreement?

  33. 4.2 Exactly how does ICANN want the data to be made available?

  34. 4.2 How will ICANN verify and ensure operational stability? What's the difference between "verifying" and "ensuring"? How would ICANN go about "ensuring"? What means "continuous" - 24x 7?

  35. 4.3 what is meant by "safety" and "integrity": are there to be written specifications?

  36. 4.3 is "mutually approved by ICANN and the sponsoring Organziaton" intended to mean something different from "agreement of the parties"?

  37. 4.3 10.2.3 of the GAC principles requires that the escrow agent or mirror site be approved by the ccTLD and the government authority. (Ignoring for the moment that there is a reference to ICANN in the CIRA/ICANN MOU) why does this agreement require ICANN agreement?

  38. 4.3 If the government authority is a party to the escrow agreement, why must ICANN also be a party?

  39. 4.3 confirm "parties" in part (2) means the parties to the escrow agreement.

  40. 4.3 is part (3) intended to mean "termination of this Agreement as permitted by this Agreement"?

  41. 4.4 Sentence 2 appears to duplicate sentence 3 in 3.3? Is there a reason for this?

  42. 4.4 Attachment D seems to go beyond the format of the request to include also the information to be supplied with the request? Is there likely to be a requirement in future for any information other than what is currently covered by the template? If yes, what (or what kind of) information?

  43. 4.4 Attachment D also includes procedural steps involved in processing the change of contact information. This goes beyond "format". Is there a reason for including these provisions in the Attachment instead of the body of the agreement?

  44. 4.5.1 These provisions are derived from GAC principles. But the GAC principles have been in place since February 2000. Furthermore, they are not drafted as a contract but merely as a statement of principles. Is it not possible to more precisely define what is required to comply with the obligations set out in this clause? In other words, what are the ICANN policies?

  45. 4.5.1 and 4.52 To what extent is compliance with the other policies required? Does this mean "compliance to the letter" or "compliance with the principles"?

  46. 4.5.2 What other topics are intended to be covered?

  47. 4.5.2 Why is this tied to "residence"? What about the case where the registry allows registrations by persons residing outside the jurisdiction who have another definable connection to the jurisdiction? As an example, CIRA allows persons who register trade-marks in Canada to hold .ca domain name registrations regardless of where they reside.

  48. 4.5.2 GAC principle 9.1.8 appears to be out of date. It is difficult to imagine many cases where the domestic government retains the authority to instruct the manager to take action or refrain from taking action, except in the case where the government actually controls the registry. Has any consideration been given to the use of different words such as "request"?

  49. 4.5.3 What interest does ICANN have in ensuring that there is a dispute resolution procedure in place? This does not seem to have anything to do with the technical operation of the registry (and arguably, falls outside of even the policies for operation of a registry.)

  50. 4.5 last. paragraph: What is the extent of the change required, in ICANN's view, to invoke the circumstances described in 4.5.2

  51. 5.1 Please confirm that the scope of policies and specifications which are to be established under this clause are confined to technical matters dealt with in Schedule H (or GAC principles 10).?

  52. 5.1 Are the specifications and policies referred to in the 2nd sentence the same as those referred to in the 3rd sentence? i.e. are the words "in addition" intended to refer to additional specifications and policies or does this merely mean that the procedures outlined in the latter part of this clause are to apply "in addition" to the procedures outlined in the ICANN bylaws, etc. If the latter, which will take precedence in dictating the mode of development: ICANNs bylaws and articles or the procedures outlined in 5.1?

  53. 5.1 (a) and (c): what is the difference between "why" in (a) and "reasons for its establishment" in (c)?

  54. 5.2 Is it not possible to specify a minimum period of time?

  55. 5.2 What is to be agreed : that the nature of the specification requires a longer period, the length of the period or both?

  56. 6.2 GAC principle 7.3 contemplates reassignment but only in the case where the ccTLD breaches the commitments described in GAC principle 10. The case described in 6.2.5 does not appear to be covered by this principle. Is it intended that clauses 6.2.1 and 6.2.3 operate in any case other than a breach of the GAC principle 10 commitments?

  57. 6.2 GAC principle 7.3 also contemplates that the governmental authority will cooperate with ICANN to remedy problems. 6.2 makes no provision for this alternative remedy. Granted that, in some legal jurisdictions, the agreement cannot impose an obligation on someone who is not a party to it, but to better reflect the GAC principles should failure of the cooperation effort not be made a prerequisite to redelegation?

  58. 6.2.1 What is considered to be "material"? Who determines how long "necessary" is?

  59. 6.2.5 Please confirm that insolvency or bankruptcy is intended to be defined by reference to the domestic law applicable to the ccTLD. What if the ccTLD can (and does) continue to operate following bankruptcy or insolvency?

  60. 6.2.5 last paragraph: Please confirm that ICANN's ability to suspend is intended to apply only after arbitration proceedings have been commenced.

  61. 6.2.5 last paragraph: how could the ccTLD "endanger the operational stability of the DNS or the Internet"? Assuming that this expression is not intended to apply to the operation of the ccTLD registry, what actions (or consequences of those actions) by the ccTLD are contemplated to fall within the meaning of this expression?

  62. 6.3 This clause permits ICANN to specify the new delegee. Why is this different from GAC principle 7.4 which requires that the government authority designate the delegee?

  63. 6.3 what is meant by "manner" in line 10?

  64. 6.3 Is the indemnity intended to include ICANN's legal fees associated with termination of the contract?

  65. 6.4 Is this intended to override the indemnity provisions in 6.3?

  66. 6.5 Why not allow for arbitration in a venue other than the country of residence of the party e.g.. Den Hague or Geneva

  67. 6.8 Is there any reason why no provision is made for a change to the addresses for notice?

  68. 6.8 What is intended by the expression "scheduled for delivery"? Is it the equivalent of putting something in the mailbox?

  69. 6.11 If the ccTLD is responsible for the operation of the ccTLD registry why is ICANN seeking to exercise control over subcontractors. The GAC principles appear to make no provision for this.

  70. 6.11.2 what is meant by "an exercise of a public right"?

  71. 6.12 There appears to be no restriction on assignment by the ccTLD in the GAC Principles. In fact, principle 7.4 contemplates that the government authority has the authority to designate a new delegee. Why does this clause place the decision with ICANN?

  72. 6.12 If the MOU with DOC is relevant to this agreement, should it not be incorporated by reference?

Attachment B

Attachment D

Attachment G

© ccTLD Managers
Page updated : 2003-05-26 19:32:19