Thanks Trang/Allan Yes there are operational differences which impacts the IANA modus operandi. 1) Policy authority For gTLDs Policy authority originates within the ICANN community and ICANN sponsored consultations. For ccTLDs Policy authority originates by the ccTLD Registry conducting a process within their respective user community and tailoring the different models of Industry Best Practice to their specific national (legal framework) circumstances. For example: the ccTLD Policy authority for Australia, UK and China all have different models. For ICANN "Sponsoring organisation" works for gTLDs but it does not work for ccTLDs as RFC1591 followed international norms of using the term "Registry Manager". 2) Technical With gTLDs the Technical parameters within which a gTLD operates is determined by ICANN based on recommendations by IETF and formulated in a contract. For example DNSSEC is developed by IETF and gTLDs registries have to use NSEC3. With ccTLDs the Technical parameters within which a gTLD operates is determined by the ccTLD Registry Manager based on recommendations by the IETF and others. For example, a large number of ccTLD do not use DNSSEC at all (as the Registry management determines the risks out weight the benefits); some ccTLDs use NSEC3 whilst others use NSEC3 with opt-out to prevent zone walking and additional zone compression benefits. 3) Legal frameworks. The legal authority for a gTLD rests in the contract the gTLD Registry has with ICANN which is subject to the legal jurisdiction of California. As a consequence, legal authority for gTLD entries in the IANA is determined by a judicial process in California. So a Judge in California can instruct that a gTLD not be delegated to a ICANN (s)elected registry operator. For ccTLD Registries each registry is subject to the legal jurisdiction in which the Registry Manager is based/incorporated. So within that jurisdiction the ultimate authority is a Court. So should a Court in that jurisdiction hear evidence that the incumbent Registry Manager needs to be replaced and so determines, the judgment will specify within a period of X days there shall be a transfer of all operational assets from incumbent Registry Manager to the new Registry operator. (In such instances there is frequently a market price payment for the assets from the new to the old... which is not disclosed). When ccTLD Registries such as .CO are purchased by Neustar IANA was not involved. ICANN/IANA is not involved in the process - IANA decides whether to update their database or not - IANA is not the master of the Registry Manager, but it is in control of entries in its database and undertakes not to break the stable operation of the TLD. For example, the .IE (Ireland ccTLD Registry) - the Registry Manager (Sponsoring organisation) is listed as University College Dublin, Computing Services Computer Centre, Belfield, Dublin City, Dublin 4, Ireland. The University has not been the Registry Manager for more than a decade as IANA has elected not to update its entry to record IE Domain Registry Limited as the Registry manger. Everything works and no harm done. There are situations where ICANN can be involved where either party wants them to be. For the incumbent ccTLD registry they can be members of the ccNSO and agree in writing to follow ICANN developed Policy. If the member of the ccNSO does not agree with the ICANN Policy (or it conflicts with the laws in which they are based) - they can withdraw and terminate membership and not be impacted by the ICANN Policy. Finally there are those ccTLDs that have contracts with ICANN that specifically determine the legal jurisdiction in which the relationship is determined - the majority being the Laws of California. <><><><> I think it is important as part of the transition process the three branches of ccTLD world are captured, the independent ccTLD, the ccNSO ccTLDs and the ICANN contracted party ccTLDs and it is clearly noted that post-transition due respect for maintaining the autonomy and integrity of the diverse ccTLD community with the principle of subsidiarity being of paramount importance. Best Paul PS: I guess for completeness (but not relevant to the debate) - depending on the country also depends on how many TLDs a user can access. In some countries their ISPs are told which TLDs users within that country (including visitors) are able to access (or not access) - some ISPs will block access to specific TLDs on their own. Some countries/ISPs allow users to access the whole IANA Root, others a subset of the IANA Root, other countries/ISPs have additional special purpose TLDs for their user community. As I travel the world, I test which TLDs are accessible and you would be surprised that sometimes large country TLDs are not accessible (or the DNS is manipulated). Quoting Alan Greenberg <alan.greenberg@mcgill.ca>:
Paul, regardless of whether it is in any of the reports, can you be more specific on the differences you are referring to. Clearly there rules on delegation are different, but are you saying that there are operational differences as well?
Alan
At 15/04/2016 09:38 PM, Trang Nguyen wrote:
Hi Paul,
You had raised the below topic for discussion in the AOB portion of the agenda on Wednesday's IOTF call. Because we ran out of time, I had suggested that we pick up this discussion in the IOTF mail list. Below is what you raised on the call:
"I've raised this a number of times on the list. Historically there has always been a difference of the way in which ccs and gTLD are handled or respected within the IANA frame work and obviously the post transition we want the difference to continue. I don't know what juncture it needs to be captured, whether it's in the Bylaws of PTI, whether it's implementation recognition in the document, implementation documentation. And I would welcome your guidance, as to how you intend to respect the differences between the authority parts for ccTLDs and gTLDs."
Could you please point to the part in the ICG, CWG or CCWG proposal that speak to any requirements for implementation on this topic?
Thank you,
Trang
_______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf