The implementation team will be publishing the answers to the Frequently Asked Questions in the document linked below. The community may submit questions on this policy implementation by writing to globalsupport@icann.org 

https://docs.google.com/document/d/1FeVSwVdmss-hGCheyjOyPsSF5NhcRFKq135X8sE94rM/edit


  1. What actions are expected of the IRT with regard to Recommendation 12 while the Board’s consultation period with the GNSO Council is ongoing?
    1. No actions are expected of the IRT or the Phase 1 Implementation Team. The Registration Data Policy Implementation team is not authorized to take any action without explicit direction from the CEO who will be directed by the Board.
  2. Is it anticipated that the items from the Phase I Final Report that were deferred to Phase II for further consideration will be part of this Consensus Policy, or will they be included in the implementation work for Phase II? 
    1. The work done in Phase 2 by the EPDP Team will result in recommendations in the Final Report for Phase 2. Those recommendations will require the Board to adopt them before implementation can be done. It is envisioned that the Phase 1 Implementation will be completed before the Board resolution for Phase 2 and therefore, the Phase 2 recommendations will result in a new implementation phase. If, however, the Phase 2 resolution is made before the Phase 1 implementation is completed, the implementation team could increase its work scope to accommodate the Phase 2 work for efficiency.
  3. Can we derive implementation requirements from purposes?
    1. The implementation team cannot derive new requirements from the purposes. That work has been done by the EPDP Team and the requirements were provided to us in a way of recommendations in the Final Report. The purposes, however, are good indicators of the EPDP Team's intent regarding requirements because the purposes underlie all of the recommended requirements that follow. There is only a requirement where there is a purpose; There can't be a requirement without a purpose to support it.
  4. Can we add or delete registration data elements during the Implementation Phase?
    1. Data Elements prescribed by the EPDP Team cannot be deleted by the Implementation Team nor new elements added. If such a change is required for implementation, it would need to go back to the GNSO Council for a direction and possibly the Board.
  5. Which requirements should be followed if there is a conflict between the Consensus Policy and the Registry Agreement or Registrar Accreditation Agreement?

    1. A Consensus Policy that is developed and implemented pursuant to the procedure set forth in ICANN’s Bylaws and due process after a Registrar’s or Registry Operator’s signing of an agreement (Registry Agreement or Registrar Accreditation Agreement) with ICANN org will supersede a conflicting provision in the agreement.  For further reference:

      1. Section 3, of the Consensus Policies and Temporary Policies Specification states  “For the avoidance of doubt, Consensus Policies that meet the requirements of this Specification may supplement or supersede provisions of the agreements between Registrar and ICANN, but only to the extent that such Consensus Policies relate to the matters set forth in Section 1.2 and 1.3 of the Consensus Policies and Temporary Policies Specification.” 

      2. Section 4.1, of the Registrar Accreditation Agreement states that "During the Term of this Agreement, Registrar shall comply with and implement all Consensus Policies and Temporary Policies in existence as of the Effective Date found at http://www.icann.org/general/consensus-policies.htm, and as may in the future be developed and adopted in accordance with the ICANN Bylaws, provided such future Consensus Policies and Temporary Policies are adopted in accordance with the procedures and relate to those topics and subject to those limitations set forth in the Consensus Policies and Temporary Policies Specification to this Agreement."

  6.  Are examples of domain names used in policy language?
    1. Yes. Examples are used for clarification as needed in the policy language. When used, they should be the names reserved for documentation purposes per RFC6761 (https://tools.ietf.org/html/rfc6761) such as “example.com.“, “example.net.“,  “example.org.“
  7. Why do we have “Definitions” sections in the policy language? Are the definitions intended solely for use as a reference to someone reading the Registration Data Policy or are they intended to have broader meaning outside these policy recommendations applicable to other policies and procedures?
    1. Some ICANN policies have definitions, while others do not. We believe that definitions are beneficial in this Registration Data Policy due to its length and complexity. The purpose of the definitions is to identify specific meanings for terms in the Policy, to avoid disputes about these after the Policy is implemented. The definitions are needed in this Policy to avoid ambiguity in interpretation, as well as to streamline the Policy. If terms are not defined in the definitions section, the language may need to be repeated in several sections of the Policy to explain the meanings of the terms; when specific terms are defined, they can be used as “shorthand” in the Policy requirements sections to make those sections easier to read and understand. The definitions to be included in this Policy will define terms for purposes o f this Policy only. They are intended to be consistent with how the words are used in the RA/RAA and other policies where applicable but don’t modify defined terms in other agreements/policies.



  • No labels