AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

PLEASE NOTE  Webinar relating to this matter => Listen  to Recording => "To give a better idea of the progress made to date and an opportunity to answer questions from community members, there will be a webinar:  The recordings of the Framework of Interpretation Webinar on Revocation today 12 November. Mp3 (audio recording) Adobe Connect Recording (visual recording including slides)=

Comment Close
Date		Statement
Name 

Status

Assignee(s) and
RALO(s)

Call for
Comments		Call for
Comments
Close 		Vote
Announcement 		Vote OpenVote
Reminder		Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
20.12.2013ccNSO FoI WG's Interim Report on "Revocation"Adopted
14Y, 0N, 0A 		Rinalia Abdul Rahim (APRALO)08.11.201310.12.201312.12.201312.12.201318.12.201319.12.201320.12.2013Bart Boswinkel bart.boswinkel@icann.orgAL-ALAC-ST-1213-02-00-EN

Comment / Reply Periods (*)

Comment Open Date: 
28 October 2013
Comment Close Date: 
20 December 2013 - 23:59 UTC
Reply Open Date: 
21 December 2013
Reply Close Date: 
31 January 2014 - 23:59 UTC
Important Information Links
Public Comment Announcement
To Submit Your Comments (Forum)
View Comments Submitted
Brief Overview
Originating Organization: 
ccNSO Framework of Interpretation Working Group (FoI WG)
Categories/Tags: 
  • Policy Processes
  • Top-Level Domains
  • Transparency/Accountability
Purpose (Brief): 

The ccNSO Framework of Interpretation Working Group (FoI WG) seeks public comment on its initial interpretations of current policy and guidelines related to "Revocation", which is defined as redelgations undertaken without the consent of the ccTLDmanager. "Revocation" refers to the process by which the IANA Operator rescinds responsibility for management of a ccTLDfrom a manager.

Current Status: 

The Interim Report is published to seek feed-back and input from the community on the proposed interpretations of the current policies and guidelines. This is part of the process for developing recommendations to the ccNSO and GAC and ultimately toICANN Board on the interpretation of current, existing policy and guidelines realting to the delegation and redelgation of ccTLD's.

Next Steps: 

The WG will closely review all submitted comments to determine at may at its reasonable discretion modify its report. According to its charter the WG is not obligated to include all comments made during the comment period, nor is it obligated to include all comments submitted by any one individual or organization.

The Working Group expects to formally publish its Final Report prior to the next ICANN meeting in London (June 2014)

Staff Contact: 
Bart Boswinkel
Email Staff Contact
Detailed Information
Section I: Description, Explanation, and Purpose: 

The FoI WG identified the applicable polices and procedure statements and reviewed past cases of re-delegations undertaken without the consent of the incumbent operator. Based on this analysis the FOIWG examined issues arising in the context of the applicable policies and procedures and developed draft interpretations summarized below.

  • RFC 1591 identifies three mechanisms available to the IANA Operator: Delegation, Transfer and Revocation.
  • Under RFC 1591, a Transfer requires the consent of the incumbent ccTLD manager.
  •  "Revocation" refers to the process by which the IANA Operator rescinds responsibility for management of a ccTLDfrom a manager.
  • The WG interprets RFC 1591 to limit Revocation to cases where the IANA Operator reasonably demonstrates that there are persistent problems with the operation of the domain, or the manager continues to engage in "substantial misbehavior", despite the efforts of the IANA Operator using all means at its disposal to resolve such conduct.
  • If a manager is engaged in "substantial misbehavior" or there are "persistent problems in the operation of a ccTLD" and the ccTLD manager is unwilling or unable to rectify the problems to the reasonable satisfaction of the IANAOperator and/or stop the offending conduct, the IANA Operator may propose a Transfer.
  •  If the manager does not consent to a proposed Transfer, the only mechanism available to the IANA Operator to deal with ultimately intractable problems is Revocation.
  • If the IANA Operator revokes a delegation it should attempt, in collaboration with the significantly interested parties, to ensure the ccTLD will continue to resolve names until a suitable replacement can take over.
  • The FOIWG believes it is consistent general principles of fairness and with RFC1591 to afford an affected manager the opportunity to appeal a notice of revocation issued by the IANA Operator to an independent body.

The FOI WG seeks community feedback on the following questions:

  1. Is the approach used by the working group satisfactory?
  2. Do the issues identified by the working group for this topic capture the major problems associated with the topic? If not what is missing?
  3. Is the proposed interpretation of the relevant sections of RFC 1591 effective and supported?
  4. Are the proposed recommendations effective in addressing the concerns raised in the final report of the DRDWG regarding this topic?
Section II: Background: 

The FOIWG was created by the ccNSO Council following the recommendations of the Delegation and Re-delegation Working Group (DRDWG): Recommendation 2: Delegation and re-delegation of ccTLDs

The DRDWG recommends that, as a first step, the ccNSO Council undertakes the development of a "Framework of Interpretation" for the delegation and re-delegation of ccTLDs. This framework should provide a clear guide to IANA and the ICANN Board on interpretations of the current policies, guidelines and procedures relating to the delegation and re-delegation of ccTLDs.

The results of the use of such a Framework of Interpretation should be formally monitored and evaluated by theccNSO Council after a pre-determined period. If the results of this evaluation indicate that the Framework of Interpretation failed to provide logical and predictable outcomes in ICANN decision making, the ccNSO Council should then launch PDPs on the delegation and re-delegation of ccTLDs.

The Final Report of the Delegation Redelegation and Retirement Working Group (DRDWG) identified the following issues pertaining to "Unconsented Redelegations":

No procedure for re-delegation of a ccTLD without the consent of the incumbent operator. RFC1591 nor ICP1 discuss the re-delegation of a ccTLD without the consent of the incumbent operator. Instead both of these documents discuss the revocation of a delegation by IANA, for cause, followed by a re-delegation to a new operator. This is somewhat confusing given that in these types of situations the revocation has never caused accTLD to be removed from the root prior to being delegated to a new operator &ndash thus trying to ensure continued resolution of the domains registered in the relevant ccTLD. This further illustrates some of the issues surrounding the re-delegation of ccTLDs without the consent of the incumbent operator.

The objective of the FOIWG is to develop and propose a "Framework of Interpretation" for the delegation and re-delegation of ccTLDs. This framework should provide a clear guide to IANA functions manager and the ICANN Board on interpretation of the current Policy Statements.

Section III: Document and Resource Links: 

The Interim Report can be found at:

Interim Report on Revocation [PDF, 220 KB]

Additional Resources:

Further information on the work of the FoI WG is available at: http://ccnso.icann.org/workinggroups/foiwg.htm

Section IV: Additional Information: 

The Interim Report addresses the third of the following topics and which will be considered individually and in the order presented:

  • Obtaining and documenting consent for delegation and re-delegation requests
  • Obtaining and documenting support for delegation and re-delegation requests from Significantly Interested Parties (sometimes referred to as Local Internet Community or LIC).
  • Developing recommendations for un-consented re-delegations
  • Developing a comprehensive glossary of the terms used for the delegation and re-delegation of ccTLDs.
  • Developing recommendations for IANA reports on delegation and re-delegation.

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download a copy of the PDF below.

 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The ALAC congratulates the ccNSO Framework of Interpretation Working Group (FOIWG) on the outcome of its work to clarify the parameters governing the revocation of ccTLD delegation by the IANA Operator.

The ALAC strongly believes that clarity on revocation parameters as well as a clear and transparent process on the part of the IANA Operator are crucial to ensure that any act of revocation is carried out with accountability, transparency, sensitivity and care, and does not in any way disrupt the continued name resolution for Internet users.

The ALAC agrees with the Working Group’s interpretation of RFC 1591, which provides for revocation as one of three mechanisms available to the IANA Operator.  We generally support the selected limits of revocation to cases where there are “persistent problems with the operations of the domain” and where there continues to be “substantial misbehavior” on the part of ccTLD managers despite the IANA Operator’s best efforts to stop the misconduct.  We are also satisfied that the Working Group has defined what constitutes “persistent problems” and “substantial misbehavior” clearly to support appropriate action by the IANA Operator.

The Working Group indicated that it had considered whether the GAC Principles and accompanying guidelines are consistent with the RFC 1591 and whether they provide an aid to the Working Group’s interpretation (Section 2.2.2).  We do not see any conclusion to these considerations.  We note that section 4.3.7.2 appears to factor the GAC Principles in specifying that “If the IANA Operator revokes a delegation it should attempt, in collaboration with the significantly interested parties to ensure the ccTLD will continue to resolve names until a suitable replacement can take over.”  As a form of good practice, we strongly recommend that the IANA Operator consult with the local government before taking action to revoke any ccTLD operator. 

We further suggest the following to strengthen the interpretation work:

  1. Specify further the appeals mechanism for the ccTLD manager in the case of revocation in section 4.3.7.3.  Operationalization of the interpretation would be more efficient if there is greater clarity on the type and geographic jurisdiction of the “independent body” that would qualify for the appeals process.
  2. Request the IANA to maintain accurate and informative reports on cases of re-delegation and to record receipts of delegation transfer consent from the incumbent ccTLD manager so as to better distinguish clear revocation cases when the IANA’s performance is reviewed.

With regard to the questions posed by the FOIWG to the community, our responses are as follows:

  1. Is the approach used by the working group satisfactory?
    Yes.

  2. Do the issues identified by the working group for this topic capture the major problems associated with the topic? If not what is missing?
    Yes for cases that involve "operational problems" and "substantial misbehavior" on the part of the incumbent ccTLD Operator.  One gap that is of concern to our community is the consideration of whether or not the IANA Operator is empowered to act in cases where there is a request for revocation from a local government, which is backed by local law, but where there are no "operational problems" and no "substantial misbehavior" on the part of the incumbent ccTLD Operator.  Clarification on how such cases will be handled by the IANA Operator is requested. 

  3. Is the proposed interpretation of the relevant sections of RFC 1591 effective and supported?
    Yes.

  4. Are the proposed recommendations effective in addressing the concerns raised in the final report of the DRDWG regarding this topic?
    Yes.

FIRST DRAFT SUBMITTED

The ALAC congratulates the ccNSO Framework of Interpretation Working Group (FOIWG) on its work to clarify the parameters governing the revocation of ccTLD delegation by the IANA Operator.

Clarity on the revocation parameters and process is crucial to ensure that any act of revocation on the part of the IANA operator is carried out with sensitivity and care, as a last resort, and does not in any way disrupt the continued name resolution for Internet users.

The ALAC agrees with the Working Group’s interpretation of RFC 1591, which provides for revocation as one of three mechanisms available to the IANA Operator.  We support the selected limits of revocation to cases where there are “persistent problems with the operations of the domain” and where there continues to be “substantial misbehavior” on the part of ccTLD managers despite the IANA Operator’s best efforts to stop the misconduct.  We are also satisfied that the Working Group has defined what constitutes “persistent problems” and “substantial misbehavior” clearly to support appropriate action by the IANA Operator.

In section 2.2.2 of its report, the Working Group indicated that it had considered whether the GAC Principles and accompanying guidelines are consistent with the RFC 1591 and whether they provide an aid to the Working Group’s interpretation.  We do not see any conclusion to these considerations.  However, we do note that section 4.3.7.2 appears to factor the GAC Principles in specifying that “If the IANA Operator revokes a delegation it should attempt, in collaboration with the significantly interested parties to ensure the ccTLD will continue to resolve names until a suitable replacement can take over.”

We further suggest the following to strengthen the interpretation work:

  1. Specify further the appeals mechanism for the ccTLD manager in the case of revocation in section 4.3.7.3.  Operationalization of the interpretation would be more efficient if there is more clarity on the type and geographic jurisdiction of the “independent body” that would qualify for the appeals process.
  2. Request the IANA to maintain accurate and informative reports on cases of re-delegation and to record receipts of delegation transfer consent from the incumbent ccTLD manager so as to better distinguish clear revocation cases when reviewing the IANA’s performance.

With regard to the questions posed by the FOIWG to the community, our responses are as follows:

  1. Is the approach used by the working group satisfactory?

Yes.

  1. Do the issues identified by the working group for this topic capture the major problems associated with the topic? If not what is missing?

Largely yes.  See the ALAC’s comment in the section above for gaps.

  1. Is the proposed interpretation of the relevant sections of RFC 1591 effective and supported?

Yes.

  1. Are the proposed recommendations effective in addressing the concerns raised in the final report of the DRDWG regarding this topic?

Yes.

  • No labels

15 Comments

  1. Rinalia Abdul Rahim

    DRAFT ALAC Statement on Revocation of ccTLD Delegation by the IANA Operator

     

    The ALAC congratulates the ccNSO Framework of Interpretation Working Group (FOIWG) on its work to clarify the parameters governing the revocation of ccTLD delegation by the IANA Operator.

     

    Clarity on the revocation parameters and process is crucial to ensure that any act of revocation on the part of the IANA operator is carried out with sensitivity and care, as a last resort, and does not in any way disrupt the continued name resolution for Internet users.

     

    The ALAC agrees with the Working Group’s interpretation of RFC 1591, which provides for revocation as one of three mechanisms available to the IANA Operator.  We support the selected limits of revocation to cases where there are “persistent problems with the operations of the domain” and where there continues to be “substantial misbehavior” on the part of ccTLD managers despite the IANA Operator’s best efforts to stop the misconduct.  We are also satisfied that the Working Group has defined what constitutes “persistent problems” and “substantial misbehavior” clearly to support appropriate action by the IANA Operator.

     

    In section 2.2.2 of its report, the Working Group indicated that it had considered whether the GAC Principles and accompanying guidelines are consistent with the RFC 1591 and whether they provide an aid to the Working Group’s interpretation.  We do not see any conclusion to these considerations.  However, we do note that section 4.3.7.2 appears to factor the GAC Principles in specifying that “If the IANA Operator revokes a delegation it should attempt, in collaboration with the significantly interested parties to ensure the ccTLD will continue to resolve names until a suitable replacement can take over.”

     

    We further suggest the following to strengthen the interpretation work:

    1. Specify further the appeals mechanism for the ccTLD manager in the case of revocation in section 4.3.7.3.  Operationalization of the interpretation would be more efficient if there is more clarity on the type and geographic jurisdiction of the “independent body” that would qualify for the appeals process.
    2. Request the IANA to maintain accurate and informative reports on cases of re-delegation and to record receipts of delegation transfer consent from the incumbent ccTLD manager so as to better distinguish clear revocation cases when reviewing the IANA’s performance.

    With regard to the questions posed by the FOIWG to the community, our responses are as follows:

    1. Is the approach used by the working group satisfactory?

    Yes.

    1. Do the issues identified by the working group for this topic capture the major problems associated with the topic? If not what is missing?

    Largely yes.  See the ALAC’s comment in the section above for gaps.

    1. Is the proposed interpretation of the relevant sections of RFC 1591 effective and supported?

    Yes.

    1. Are the proposed recommendations effective in addressing the concerns raised in the final report of the DRDWG regarding this topic?

    Yes.

    END

  2. Evan Leibovitch

    Two questions regarding the real-world outcomes of this work:

     

    1. Does this activity at all enable anyone to address the issues related to oversight of dot-su?
       
    2. Also: I would like to hear from anyone who was following the controversy regarding the re-delegation of the Puerto Rican domain, a matter with which NARALO was briefly involved. Do the activities of the WG address, going forward, the severe transparency issues that caused the re-delegation of .pr to be so controversial?

    1. Eduardo Diaz

      Evan:

      I am preparing some comments to add to this statement if we all agree. These are based on the experiences that we had with the IANA processes and their interpretation of the RFC1591 when the Internet Society of Puerto Rico submitted a re-delegation request for .pr. In our case, we were requesting a revocation based on the  support from "significantly interested parties" which included the local Internet community of end-users, major businesses and business organizations and the government. 

       

       

       

  3. Eduardo Diaz

    The FOIWG makes it very clear in section 4.3.5.3 that any ccTLD revocation by the IANA operator should be based EXCLUSIVELY on the competence and behavior of the ccTLD manager with respect to the stability and security of the DNS and/or the continuing operation of the domain. 

    The Internet Society of Puerto Rico (ISOCPR) and representatives from the government of Puerto Rico were given the run around by the IANA operator during the failed re-delegation of the .pr because the IANA operator did not clearly define the parameters required for a re-delegation request (or a revocation for that matter) based on the lack of equitable, honestly and competence by the ccTLD manager. This resulted in wasted efforts by parties, misunderstandings and poverty of transparency through the whole process. Having known this interpretation from the beginning we would have done things differently. ISOCPR is very pleased to see that these issues are being tackled finally. 

  4. Eduardo Diaz

    I suggest to change the second paragraph to read as follows:

    ---

    The ALAC strongly believes that clarity on the revocation parameters and a clear and transparent process on the part of the IANA operator is crucial to ensure that any act of revocation is carried out with transparency, understanding, sensitivity and care and does not in any way disrupt the continued name resolution for Internet users.

    ---

    Change answer in question #2 to the following:

    ---

    Yes. Missing is a clear interpretation for the case where a government requests a revocation without the ccTLD manager consent.  

    ---

    Revise the formating in the questions lists.

     

     

     

  5. Rinalia Abdul Rahim

    REVISED ALAC Statement on Revocation of ccTLD Delegation by IANA Operator

     

    The ALAC congratulates the ccNSO Framework of Interpretation Working Group (FOIWG) on its work to clarify the parameters governing the revocation of ccTLD delegation by the IANA Operator.

     

    The ALAC strongly believes that clarity on the revocation parameters and a clear and transparent process on the part of the IANA operator are crucial to ensure that any act of revocation is carried out with transparency, understanding, sensitivity and care, and does not in any way disrupt the continued name resolution for Internet users.

     

    The ALAC agrees with the Working Group’s interpretation of RFC 1591, which provides for revocation as one of three mechanisms available to the IANA Operator.  We support the selected limits of revocation to cases where there are “persistent problems with the operations of the domain” and where there continues to be “substantial misbehavior” on the part of ccTLD managers despite the IANA Operator’s best efforts to stop the misconduct.  We are also satisfied that the Working Group has defined what constitutes “persistent problems” and “substantial misbehavior” clearly to support appropriate action by the IANA Operator.

     

    In section 2.2.2 of its report, the Working Group indicated that it had considered whether the GAC Principles and accompanying guidelines are consistent with the RFC 1591 and whether they provide an aid to the Working Group’s interpretation.  We do not see any conclusion to these considerations.  However, we do note that section 4.3.7.2 appears to factor the GAC Principles in specifying that “If the IANA Operator revokes a delegation it should attempt, in collaboration with the significantly interested parties to ensure the ccTLD will continue to resolve names until a suitable replacement can take over.”

     

    We further suggest the following to strengthen the interpretation work:

    (1)   Specify further the appeals mechanism for the ccTLD manager in the case of revocation in section 4.3.7.3.  Operationalization of the interpretation would be more efficient if there is more clarity on the type and geographic jurisdiction of the “independent body” that would qualify for the appeals process.

    (2)   Request the IANA to maintain accurate and informative reports on cases of re-delegation and to record receipts of delegation transfer consent from the incumbent ccTLD manager so as to better distinguish clear revocation cases when reviewing the IANA’s performance.

     

    With regard to the questions posed by the FOIWG to the community, our responses are as follows:

    (1)   Is the approach used by the working group satisfactory?

    Yes.

    (2)   Do the issues identified by the working group for this topic capture the major problems associated with the topic? If not what is missing?

    Yes.  Gaps include a clear interpretation for the case where a government requests a revocation without the incumbent ccTLD manager’s consent.  

    (3)   Is the proposed interpretation of the relevant sections of RFC 1591 effective and supported?

    Yes.

    (4)   Are the proposed recommendations effective in addressing the concerns raised in the final report of the DRDWG regarding this topic?

    Yes.

    END

  6. Anonymous

    I think that the case of transfer or revocation request is clear - no transfers without ccTLD manager agreement. Revocation is a last resort, only in the case of substantial misbehaviour and persistent problems, and those are also clear. So I do not think it necessary to single out this one case of government request, as opposed to any other stakeholder request. Jacqueline

    1. Eduardo Diaz

      In the context of revocations I do not consider the government to be a stakeholder.  The interpretation is very clear that if any stakeholder requests a revocation for whatever reason without the ccTLD manager consent it will be pushed back to the local level to be resolved.  However the interpretation is not clear in the case when the government of a country requests a revocation for whatever reasons without the consent of the ccTLD manager. It is not clear if IANA will be obligated to do it or send it back to be resolved locally.  

      1. Jacqueline Morris

        Not revocation, transfer. CcTLD manager agreement is required for transfer, not revocation.

  7. Carlton Samuels

    Should a revocation request from government be given extra scrutiny or not?  If so, should there not be a higher threshold for a revocation request originating from the govt. to prevail?

    Carlton 

    1. Eduardo Diaz

      Whatever the processes or requirements are, the interpretation should be very clear for this specific case.  Will this type of case be sent back if there is no ccTLD manager consent attached to it?

      1. Jacqueline Morris

        If it reaches revocation, the ccTLD manager is removed from the equation. The ccTLD manager consent is required for transfer, not revocation. Obviously, since revocation is when the ccTLD manager is seriously and persistently in breach, it makes no sense for the IANA to send back for ccTLD consent. Jacqueline

        1. Eduardo Diaz

          The point is that revocation without the ccTLD manager consent is being interpreted by the WG for cases where the manager is seriously and persistently in breach of technical abilities to resolve its domains. It does not interpret a revocation when a government has a mandate for revocation without the ccTLD manager consent for any cause other than the ccTLD manager technical abilities. The applicability of "local law" within the context of revocation in the RFC 1591 should be clearly interpreted by the WG to cover cases like this.

  8. Anonymous

    "Revocation" is a component in the whole Framework of Interpretation (FoI) structure and should be viewed in the framework. It is the very last resort--a kill switch-to act on. Before moving to IANA for action, all the "significantly" interested stakeholder groups should have been involved, consulted and voiced.  The interpretation of "local law" should have been done before this step, rather than being referred back from IANA to local authority upon revocation. Hong   

    1. Eduardo Diaz

      Hong Xue

      I am not sure I understand your comment with regards to the "interpretation of local law". As far as I know the framework of interpretation WG has not interpreted the applicability of "local law" within the context of revocation in the RFC 1591. The question still stands: if a government with a mandate to revocate without the ccTLD manager consent for whatever cause other than technical competence will it be sent back to be resolved locally by the IANA operator?