| Home | | | Meetings | | | AdCom | | | ccTLD | | | Participants |
http://www.icann.org/cctlds/model-tscsa-02sep01.htm
http://www.icann.org/cctlds/model-legacy-mou-02sep01.htm
Eric Barbry
Written after CENTR meeting in Bled, Slovenia, in September 2001
The purpose of this memorandum is to provide a detailed audit of the model ICANN - ccTLD Manager Memorandum of Understanding . Legacy Situation (MoU) and Model ccTLD Sponsorship Agreement . Triangular Situation (Triangular Agreement) taking into consideration the discussion of the agreements at CENTR's General Assembly in Bled.
ICANN and the ccTLD registries have been working to create a formal relationship and in 2000 CENTR sent its own proposal to ICANN for an agreement.
ICANN did not respond to this proposal and on September 2, 2001 posted the MoU and Triangular Agreement.
The following will provide an analysis of such agreements. It must be clear that the following is simply a clause-by-clause analysis of the proposed contracts by ICANN and in no way pertain to the contract submitted by CENTR nor should it be considered as a proposal of any kind.
Before specifically discussing the agreements, there are several issues that must be considered.
The following discusses three reasons why the parties may fee a contract is necessary.
A ccTLD registry may feel it needs formal and official acceptance or recognition from ICANN for confirmation of its position as a registry.
It must be first noted that, as will be explained below, recognitions is not needed. However, if this is really what the parties intended, a contract is not the best manner in achieving this acceptance. In fact, a formal contract risks causing problems in the future. For example, once the contract is terminated, recognition is lost and the registry will no long be considered a registry.
In order to satisfy the ccTLD Registry's desire to have formal recognition, if this is so desired, a simple letter of recognition is enough for ICANN to confirm the registry is the registry of a domain name zone. Additionally, a letter is more appropriate with regards to recognition because it does just that and does not have negative consequences in the future.
If it is not a problem of recognition, it may just be that the parties feel there needs to be specific delegation and redelegation rules.
Here too, a contract is not necessary. What is really needed is a policy. The advantage of a policy is that it would be applicable to all ccTLD registries. With a contract, as it has become evident, each ccTLD registry will have to contract separately with ICANN. However, a general policy would maintain the same regulations for all registries and would enable consistency in the industry.
Finally, if this is strictly about the services needed from ICANN again, there are alternative solutions to contracting
For example, the ccTLD registry could simply place an order with ICANN specifying its needs. This would allow the needs to be defined without the ccTLD registry binding itself to obligations or shortcomings that may be found in a contract.
If the parties choose to contract, however, the type of contract needed must closely be examined. It seems that in the model agreements ICANN will be providing services to the ccTLD registries that in turn will pay a fee. Therefore, it seems as if this is a services agreement.
Therefore, in reading the model agreements, it must be remembered that the only obligation the ccTLD Managers or Sponsoring Organization should have is to pay the fee for the services.
It is evident these contracts fix greater obligations for the CCTLD Manager or the Sponsoring Organization.
This issue deserves its own section because it may be seen throughout the MoU and the Triangular Agreement.
The MoU has a recognition clause for both the ccTLD Manager and ICANN. This is particularly problematic for the ccTLD manager because this clause implies that the registry did not exist before the signing of the contract and will not exist after termination of the contract which, in fact, is not the case. Most of the ccTLD registers have been considered as such for a while and are not and should not be dependent on ICANN to be considered as the registry for a territory. What is especially dangerous is the fact that if the MoU or the Triangular Agreement is terminated, the current ccTLD registry will not be considered as such.
The problem of recognition is further illustrated in the Triangular Agreement. The recognition clause is officially stated under section 3.1; however, the effects are found throughout the agreement. For example, clauses 1.2, 1.3, and 1.4 all imply recognition of the ccTLD. Clause 1.2 pertains to ICANN recognition of the Sponsoring Organization, clause 1.3 pertains to its recognition by the IANA ("a function performed by ICANN"), and finally, clause 1.4 pertains to its recognition by the government of its territory.
Therefore, currently, the ccTLD registries do not have official recognition by ICANN and this contract implies that without this official recognition the organization could not possibly be the ccTLD registry.
Finally, clause 6.3 of the Triangular Agreement specifically states that without ICANN recognition it will no longer be considered as the manager of the ccTLD. Specifically, this clause states that if the contract is terminated, the Sponsoring Organization will transfer the data to the "specified successor". Furthermore, it states, "The Sponsoring Organization acknowledges that upon termination of this Agreement it will cease to be the recognized manager of the Delegated ccTLD" and the ccTLD also agrees to the reassignment of the ccTLD. Again, this is another illustration that if the contract is terminated, the Sponsoring Organization will no longer be considered to exist.
Also, it must also be noted that in the Triangular Agreement there is no recognition clause for ICANN.
Therefore, should the parties decide they need a contract, the recognition provisions need to be modified in each contract simply to state who the parties currently are and what they do. The existence of the parties may not depend on recognition.
This is similar to the problem of recognition in that calling the ccTLD .Delegated ccTLD. implies that ICANN chose this registry as opposed to others in the same territory. Therefore, this term should not be used throughout the contracts. The Sponsoring Organization of the ccTLD Manager is the current ccTLD registry and does not need to be delegated by ICANN.
Although the issue of recognition has been covered above in clauses 1.2 and 1.4, they must be further discussed.
Clause 1.2 specifically states that the Sponsoring Organization has the .intention of managing the .[insert Delegated ccTLD code]... Again, is must be understood that the organizations already manage the ccTLDs. There is not simply an intention to do so.
Also, clause 1.4 creates problems because it is requesting that a communication between the Governmental Authority and the Sponsoring Organization be annexed to the Triangular Agreement. The Governmental Communication is defined as laws, agreements, documents or any sort of writing that regulates the relationship between these parties.
This is a difficult request because this is something many sponsoring Organizations will not be able to provide. For example, a law may be in the process of being created but not yet enacted and, if this is the case, the Sponsoring Organization is unable to fulfill this obligation. This merits further discussion.
There are also perhaps other options than attaching a communication between a Governmental Authority and a Sponsoring Organization that may be considered. For example, if a contract with the government or a law is unavailable, the same function may be accomplished by simply adding an article in the agreement regarding liability, which explains that the Sponsoring Organization will manage every problem that arises under its duties. This is essentially a manner to state that the Sponsoring Organization manages or operates the ccTLD code domain space.
Furthermore, clause 1.5 requests a communication between the Governmental Authority and ICANN in which the Governmental Authority designates the Sponsoring Organization as the "Delegated ccTLD". This clause must be reviewed because it gives the Governmental Authority an obligation to annex a document and the Governmental Authority is not even a party to the agreement. Therefore, this may be difficult to enforce because this clause essentially places an obligation on a non-party.
Placing an obligation on a non-party is also seen in clause 1.7 of the Triangular Agreement. The parties of the agreement, by requesting the Governmental Authority to assume responsibility in supervising the country or territory interest, is once again asking something from the Governmental Authority who is not a party to the contract.
Finally, in the Recitals, clause 1.6 must be examined because it states that the Sponsoring Organization wrote a letter to ICANN stating it would perform different obligations concerning the ccTLD code top-level domain. This clause needs to explain what kind or letter as well as the contents of the letter. Furthermore, it must be remembered that the only obligation should be payment.
Several definitions need to be modified. For example, "Delegated ccTLD", as mentioned above, should be modified to simply reading "ccTLD".
Additionally, "Governmental Authority" should be further defined. Sometimes the ccTLD managing a county code is not from the same nationality as the country code it represents. The question becomes, which government applies? Is it the government that manages the country code or is that the country whose nationality the country code belongs? This must be defined in order to avoid ambiguity.
Finally, as discussed in Bled, the definition of Sponsoring Organization is ambiguous and must be clarified.
The first clause under ICANN Obligations is the Sponsoring Organization's recognitions clause. Although this has been discusses at length above, it must again be pointed out that there is no corresponding clause to recognize ICANN. In the MoU, on the other hand, there is a recognition clause for both parties. It would be interesting to understand why there is this discrepancy between the two agreements.
In fact, often there are discrepancies between the agreements and they will be pointed out throughout the foregoing memorandum.
ICANN's second obligation is to "maintain, or cause to be maintained a stable, secure and authoritative database".. It must first be noted that the MoU states, "authoritative publicly available database". It is unclear why there is this inconsistency between the MoU and the Triangular Agreement.
Also, under this provision, the terms "stable" and "secure" are unclear. The meaning of these words must be determined. If not, there is no standard and the parties will not know if stability has been reached or what the other considers secure.
Finally, the second obligation also states that ICANN may cause the database to be maintained. It seems as though this implies that ICANN may subcontract. However, there is no clause that discusses subcontracting for ICANN. On the other hand, there is a clause that regulates the subcontracting of the Sponsoring Organization. It would seem to make more sense if both parties were held to the same obligations.
Clause 3.3 pertains to the designation of administrative and technical contacts and states that the Sponsoring Organization may request a change of these contacts in writing and must provide "complete and accurate contact information" in this writing. First of all, how can ICANN be sure it is the Sponsoring Organization that is sending the writing when it is not done so in person?
Secondly, it is unclear what exactly is "complete and accurate contact information" and this should be defined. Thirdly, the clause states that ICANN will change the information if it is "reasonable satisfied that the request is genuine". Without knowing what information to give, there is always the chance the Sponsoring Organization will not give enough information to .reasonably satisfy. ICANN. This must be clarified.
This notion that ICANN must be "reasonably satisfied that the request is genuine" is also found in clauses 3.4 and 3.5. In a sense, by requesting this information, ICANN controls the information. It would seem under a services agreement, it is the Sponsoring Organization's choice concerning what information to give ICANN to place in the database and ICANN does no have the power to control the information provided by the Sponsoring Organization. If the Sponsoring Organization has made a mistake, it will be the Sponsoring Organization who is liable; therefore, ICANN should not have this control.
Clause 3.6 which regards publication of Root-Zone Whois Information of the foregoing agreement is inconsistent with the MoU. It is clear that there are areas which are more specific in the Triangular Agreement, however, it should be explained why this is the case in technical and administrative issues in the contracts?
Furthermore, in the clause, it again states that ICANN may "cause [the data] to be published". Again, this implies the notion of subcontracting which is not discussed in the agreement.
Clause 3.7 should be discussed because again it mentions "a stable and secure manner" which should be defined. Also, it sets a standard of "reasonable commercial efforts". It must be clarified why a lower standard is set for the Authoritative Root-Server System.
Under clause 3.8 a subcontract is again implied. The Sponsoring Organization is not given any indication or how, who, or when this subcontract will take place.
Finally, clause 3.10 must be reviewed. This clause specifically states that the sponsoring Organization may use a logo to "state that it is recognized by ICANN as the Sponsoring Organization". Once again the issue of recognition resurfaces, and as mentioned above, is not accurate because the Sponsoring Organization existed before ICANN's recognition. Furthermore, this clause is not in the MoU.
There are various discrepancies in clause 4.1 and 4.2 as opposed to the same clauses in the MoU. For example, clause 4.1 specifically mentions .authoritative primary and secondary nameservers. whereas the MoU simply states .authoritative nameservers.. Furthermore in this clause, the Triangular Agreement includes the category of sub-domains. Finally, the Triangular Agreement in clause 4.2 it is added that ICANN may .from time to time reasonably specify. the manner in which the zone-file and registration data are to be available to it whereas in the MoU there is no mention of the manner. It is important to find out why there are these differences in the two agreements.
Furthermore, the above problem of a lack of clear standard with regards to "stable and secure manner" may again be seen in clause 4.1. These terms must be clarified.
A ccTLD Registry Data Escrow clause, clause 4.3, is found in the Triangular Agreement and not in the MoU. This clause is problematic because it places all the Sponsoring Organization's information in a data escrow, which in turn places ICANN, in a position that is not necessarily ICANN's proper position. For example, if ICANN is unhappy in the manner that the Sponsoring Organization is managing the ccTLD, under this agreement, it may terminate the relationship. If all the information is in a data escrow, ICANN will take the information, as stated in the clause, and provide the information to the successor manager who, by the way, under clause 6.3, ICANN chooses.
It must be remembered that the Sponsoring Organization is not dependent on ICANN's recognition and even after the signing of an agreement would continue to exist independently.
Also, this is a services agreement yet it gives ICANN the control to take all the Sponsoring Organization's information and provide it to another organization it chooses.
Furthermore, under clause 4.4, the Sponsoring Organization has the obligation of maintaining accurate and complete contact information. Again, this is the Sponsoring Organization's problem. This should not be an obligations imposed by ICANN. If the Sponsoring Organization has inaccurate information, it will be liable for its information, not ICANN.
Clause 4.5 pertains to the conformity to ICANN's policies. Again, there is a discrepancy with the MoU. Under the MoU it just simply states that the ccTLD Manager must conform to ICANN's policies whereas this clause is much more detailed.
Additionally, it must be remembered that the Sponsoring Organization is independent from ICANN and it has simply requested services from ICANN. Each country has their own policies to follow and, as a service agreement, ICANN's policies are not the subject of this agreement. Therefore, there should no be such obligation.
Finally, the financial contributions clause must be discussed. In the present agreement there is an attachment that discusses the limitation on the contribution requirements. This attachment must be reviewed to determine the benefits for each party. The specifics of this clause are discussed in the foregoing memorandum under section 5.1.4.
This clause seems to make reference to several standards such as the ICP-1 paragraph (d). Therefore, it should just be pointed out that these standards need to be verified in order to make sure they are not outdated.
Furthermore, this clause pertains to .new or revised ICANN specifications. and, although it does allow the Sponsoring Organization time to comment, it needs to be reviewed. In closely examining this situation is seems as if this is a one on one process. This is problematic because it seems that if new specifications were to be adopted, everyone should adopt them at the same time. All Sponsoring Organizations and ICANN should work together in adopting new specifications. The provision implies ICANN has a freedom to change specifications which could be dangerous for the Sponsoring Organization.
Termination by the Sponsoring Organization is first established in the agreement. This provision is not clear because in reality the Sponsoring Organization will either transfer the data to another Sponsoring Organization or decide with its government at that there will be no ccTLD in the geographic zone. Therefore, in order clarify this provision, it should explain when termination might take place and the consequences of such termination.
Clauses 6.2 and 6.3 do not seem to apply to the current situation. Because this is a service contract, the Sponsoring Organization's only obligation is to pay. Therefore, if there is some sort of mistake, this is something the Sponsoring Organization and its government must deal with and not ICANN. Termination could only occur if the Sponsoring Organization did not pay its fees.
Furthermore, because the Sponsoring Organization is independent from ICANN and exists even without ICANN's recognition, ICANN may not choose a successor, as is stated in clause 6.3. It must just be pointed out one more time that the ccTLD is an ISO code and is the property of the country in which it belongs. Therefore, it is not ICANN's duty to choose the successor.
This clause needs to be reworked because it essentially states that the Sponsoring Organization will pay for its services and, if ICANN breaches the agreement, the Sponsoring Organization will not be able to ask for damages. The Sponsoring Organization has paid so it must be allowed to request damages.
There are a few issues which need to be pointed out with regards to ICC arbitration. First, it is very expensive. Second, currently there are no specialists on domain name issues. Therefore, although the idea of arbitration is not problematic, it is important to prepare with the ICC before this clause is utilized.
Also, this clause specifies that by default arbitration will take place in New York and all stays, temporary or preliminary injunctive relief will be in front of a panel in Los Angeles, California in the United States regardless who brings forth the claim. A more appropriate clause would be to simply state that the tribunal in the state of the defendant should be used. This is also applicable regarding the Choice of Law provision.
Furthermore, It must be mentioned that there are two choices with regards to arbitration. The parties can give the arbitration court all the power, such as, where to meet, applicable law, number or arbitrators or all the issues may be organized before the arbitration. It would seem that to give the court all the powers may be dangerous and it may be beneficial to both parties to work out all the terms of arbitration.
Finally, it must be noted that is several countries it may be prohibited for the State to go before an arbitration court. For example, in some countries, the State is prohibited to go before an arbitration court if the matter pertains to national issues as opposed to international issues. While in this case it would be an international issue, each Sponsoring Organization must check the law in its country.
It must simply be pointed out that notices are sent to the Government Authority who, again, is not a party to the agreement.
Why not use GMT instead of Los Angeles, California, USA time?
It would seem it would be beneficial if the subcontracting clause could pertain equally to all the parties of the agreement.
Again, it would be important to have an equivalent clause for the parties. Here, it seem the Sponsoring Organization must ask for authorization while this is not the case for ICANN.
The recitals specifically state this MoU is simply to formalize the relationship between the parties and is temporary until the parties sign a more binding agreement. The .ICANN Montevideo Meeting Topic: Update on ccTLD Agreements. posted on the ICANN website on September 2, 2001 even states that the MoU is .provisional and interim in nature..
It must be asked why the legacy situation may not be written as a definitive contract as opposed to a memorandum of understanding.
This issue has been discussed above but the main difference with the Triangular Agreement is that there is recognition of ICANN. However, this clause only states that the ccTLD Manager .acknowledges. ICANN which is much different than .recognizes.. In other worlds, ICANN does not depend on the recognition of the ccTLD Manager to exist but the ccTLD Manager does depend on ICANN's recognition.
Furthermore, recognition is particularly dangerous with a memorandum of understanding because such documents may easily be terminated? If the foregoing MoU is signed as such, the terms of recognition are accepted which will be very dangerous for the ccTLD Manager.
ICANN's obligations are similar in both contracts. There are some differences that have been pointed out under section 4.1.3 of the present memorandum, such as, that the MoU states .authoritative publicly available database. whereas the Triangular Agreement states .authoritative database.. Furthermore, the MoU does not maintain an attachment concerning .Specification for ICANN's Publication of Root-Zone Whois Information. and does not have a clause concerning the use of ICANN's name and logo. These differences should be explained.
However, except for the above discrepancies, because the obligations remain identical the same discussion that was presented for the Triangular Agreement may be utilized.
Clauses 4.1, 4.2, and 4.3, and their discrepancies with the Triangular Agreement have already been discussed under section 4.1.4 of the present memorandum.
Clause 4.4 states that the ccTLD manger must maintain a website with information about itself, as well as its procedures. Although, because again this is a services agreement the ccTLD Manager's only obligation should be to pay, it is interesting to find out why this obligation was not also imposed on ICANN.
Finally, Clause 4.5 discusses the financial contributions to ICANN. The financial contributions are not clear. In essence, the financial contribution is determined by the cost of operations with regards to an equitable scale. The cost of the operations and the equitable scale are not defined. Furthermore, how often will the financial contributions be renegotiated? Is there a limitation on these contributions? If the parties do not agree, is the only solution termination of the agreement? The Triangular Agreement has an attachment that includes limitations on the cost; however, it is not included in the MoU.
Although the clause pertaining to conformity with ICANN's policies are not identical in both agreements, they both essentially say that the ccTLD Manager or the Sponsoring Organization must conform to ICANN's policies. Again, because the ccTLD Manager is an independent organization and has its own policies and because this is a services agreement, it is not obligated to conform to ICANN's policies.
Furthermore, clause 5.2 pertains to the procedure of establishment pertaining to ICANN specifications. Again this should be a policy that is adopted by everyone. It is dangerous for the ccTLD if ICANN has the freedom to change the specifications.
Either party may implement the termination provision here with 30 days prior notice. This is consistent with a MoU.
Although this is simply a MoU, the ccTLD Manager is still paying for the services. Therefore, if ICANN breaches the agreement, the ccTLD Manager should be able to request damages.
As in the Triangular Agreement, the Choice of Law clause states that the law of its country judges the ccTLD, ICANN is judged by the laws of California in the United States, and, with a difficulty with interpretation, the law of the country which seems the most appropriate is applied.
At times it may be difficult to determine which law is appropriate. Therefore, as suggested above, it could just be decided that all cause of actions must be brought forth in the tribunal in the defendant's state.
All additional clauses are identical to the clauses in the Triangular Agreement and have been discussed above.