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
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
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
Sorry for the typo in the earlier mail - this one is corrected! Have a good w/end all <><><> 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 ccTLD operates is determined by the ccTLD Registry Manager based on recommendations by the IETF and others including local technical forums. 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
Trang I've re-read parts of the CWG proposal and whilst care was taken to ensure both ccNSO ccTLDs and non-ccNSO ccTLDs were equal, most or all of the (new) language refers just to the ccNSO. Please make sure that the interests of non-ccNSO member ccTLDs are (at least) equally well protected as ccNSO member TLDs and gTLDs in ALL cases. Rough draft - suggested text: ICANN, shall not directly or indirectly act in a manner that is detrimental to existing IANA/PTI customers of a [country code] top level domain registry without the explicit written consent of the registry operator. Hope this is helpful Best Paul Quoting Paul M Kane - CWG <paul.kane-cwg@icb.co.uk>:
Sorry for the typo in the earlier mail - this one is corrected!
Have a good w/end all
<><><>
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 ccTLD operates is determined by the ccTLD Registry Manager based on recommendations by the IETF and others including local technical forums. 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
_______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf
Paul, I am not comfortable with that wording. What is "detrimental" is a very subjective issue. That wording would require that ICANN get written approval from every ccTLD operator before changing anything. Since it is unlikely that one could get a even any reply from EVERY ccTLD, that is not a workable solution. Alan At 18/04/2016 11:56 AM, Paul M Kane - CWG wrote:
Trang
I've re-read parts of the CWG proposal and whilst care was taken to ensure both ccNSO ccTLDs and non-ccNSO ccTLDs were equal, most or all of the (new) language refers just to the ccNSO. Please make sure that the interests of non-ccNSO member ccTLDs are (at least) equally well protected as ccNSO member TLDs and gTLDs in ALL cases.
Rough draft - suggested text:
ICANN, shall not directly or indirectly act in a manner that is detrimental to existing IANA/PTI customers of a [country code] top level domain registry without the explicit written consent of the registry operator.
Hope this is helpful
Best
Paul
Quoting Paul M Kane - CWG <paul.kane-cwg@icb.co.uk>:
Sorry for the typo in the earlier mail - this one is corrected!
Have a good w/end all
<><><>
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 ccTLD operates is determined by the ccTLD Registry Manager based on recommendations by the IETF and others including local technical forums. 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
_______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf
_______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf
Hi Alan I don't think the word "detrimental" is great either!! :-) .... but I hope you understand the intent - feel free to make suggestions. My goal is to obtain reassurance in the docs that customers of ccTLD Registry will enjoy stable PTI operation of post transition. What is not captured in the current PTI/ICANN docs is the status quo as defined in the current NTIA Statement of Works as to the manner in which ccTLDs should be treated... I would note that PTI does not have any authority to try to impose policy conditions on ccTLDs beyond that which can reasonably be deduced from RFC1591 or that a ccTLD has explicitly agreed to. To assist with specifics, the most important are: Performance exclusion, section C 8.3. agreements or negotiation document with ICANN are not a requirement to receive IANA services. Fees: section 2.3, IANA provides a no-cost service to customer, although ccTLD customers are at liberty (and do) make (voluntary) contributions to ICANN a percentage of which is used to fund IANA. The goal is to avoid discriminatory practice ie if you pay you get service; if you don't, you don't (or it is slow service). So to record that PTI will continue to deliver service free from charge captures the status-quo and avoids (potential) abuse of position and disenfranchising certain TLD operators. C 2.5 Separation of operational role and policy development. Subsidiarity: C2.9.2. c Subsidiarity prevalence of ccTLD management - it's a local matter which is not included at all ... which is very different from gTLDs contractual relationship with ICANN. Regarding the CWG proposal itself: Annex C - Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship for Names Functions; Section 7ii is very clear: Post-transition of the IANA Functions, the IANA Functions Operator will continue to provide service to existing registries in conformance with prevailing technical norms, conforming with the policy decisions of registries and the security and stability of the Root Zone itself. None of the above is captured in the new ICANN/PTI documents, and silence is not acquiescence, so IMHO the way to do it, is either enshrine it in bylaws or in contract PTI- ICANN and I welcome any wording suggestions. Best Paul Quoting Alan Greenberg <alan.greenberg@mcgill.ca>:
Paul, I am not comfortable with that wording.
What is "detrimental" is a very subjective issue. That wording would require that ICANN get written approval from every ccTLD operator before changing anything. Since it is unlikely that one could get a even any reply from EVERY ccTLD, that is not a workable solution.
Alan
Trang
I've re-read parts of the CWG proposal and whilst care was taken to ensure both ccNSO ccTLDs and non-ccNSO ccTLDs were equal, most or all of the (new) language refers just to the ccNSO. Please make sure that the interests of non-ccNSO member ccTLDs are (at least) equally well protected as ccNSO member TLDs and gTLDs in ALL cases.
Rough draft - suggested text:
ICANN, shall not directly or indirectly act in a manner that is detrimental to existing IANA/PTI customers of a [country code] top level domain registry without the explicit written consent of the registry operator.
Hope this is helpful
Best
Paul
Quoting Paul M Kane - CWG <paul.kane-cwg@icb.co.uk>:
Sorry for the typo in the earlier mail - this one is corrected!
Have a good w/end all
<><><>
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 ccTLD operates is determined by the ccTLD Registry Manager based on recommendations by the IETF and others including local technical forums. 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
At 18/04/2016 11:56 AM, Paul M Kane - CWG wrote: -
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
_______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf
_______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf
Trang To assist in tonight's call I'd just like to know where Annex C, sections 7 and 8 of the CWG proposal are captured in the transition documents/Bylaws. Annex C - Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship for Names Functions https://community.icann.org/pages/viewpage.action?pageId=53779816 This important element that of of great interest to ccTLD seem to be missing....... Best Paul PS - I invite you to speak with bart.boswinkel@icann.org as he is very aware of the need to respect the diverse ccTLD community.
Paul, I am assuming that you are referring to the following from Annex C: "8) Diversity of the customers of the IANA Functions: i) The IANA Functions operator needs to take account of the variety of forms of relationship with TLD operators. The proposal will need to reflect the diversity of arrangements in accountability to the direct users of the IANA Functions. ii) For ccTLDs, the IANA Functions Operator should provide a service without requiring a contract and should respect the diversity of agreements and arrangements in place for ccTLDs. In particular, the IANA Functions Operator should not impose any additional requirements on the registry unless they are directly and demonstrably linked to the global security, stability, and resilience of the DNS. " Am I correct on that? Chuck -----Original Message----- From: iotf-bounces@icann.org [mailto:iotf-bounces@icann.org] On Behalf Of Paul M Kane - CWG Sent: Wednesday, April 20, 2016 1:02 PM To: iotf@icann.org Subject: [IOTF] AoB - Paul Kane - Annex C of CWG section 7 and 8. Trang To assist in tonight's call I'd just like to know where Annex C, sections 7 and 8 of the CWG proposal are captured in the transition documents/Bylaws. Annex C - Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship for Names Functions https://community.icann.org/pages/viewpage.action?pageId=53779816 This important element that of of great interest to ccTLD seem to be missing....... Best Paul PS - I invite you to speak with bart.boswinkel@icann.org as he is very aware of the need to respect the diverse ccTLD community. _______________________________________________ IOTF mailing list IOTF@icann.org https://mm.icann.org/mailman/listinfo/iotf
participants (4)
-
Alan Greenberg -
Gomes, Chuck -
Paul M Kane - CWG -
Trang Nguyen