AT-LARGE GATEWAY
At-Large Regional Policy Engagement Program (ARPEP)
At-Large Review Implementation Plan Development
Page History
| Comment Close Date | Statement Name | Status | Assignee(s) and | Call for Comments | Call for Comments Close | Vote Announcement | Vote Open | Vote Reminder | Vote Close | Date of Submission | Staff Contact and Email | Statement Number |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 28.03.2013 | Proposed 2013 RAA Posted for Comment | Adopted 14Y, 0N, 0A | Alan Greenberg (NARALO) | 28.03.2013 | 09.04.2013 | n/a | 11.04.2013 (ALAC Meeting in Beijing) | n/a | 11.04.2013 | 11.04.2013 | Samantha Eisner samantha.eisner@icann.org | AL/ALAC/ST/0413/3 |
(*) 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
ALAC Statement on the RAA as posted 7 April 2013
The ALAC is generally supportive of the RAA and associated specifications as posted for comment. Moreover, the ALAC is generally in agreement with ICANN on the issues where ICANN and Registrars disagree.
The proposed RAA is much better than its predecessor. It provides clarity where previously obscurity and even obfuscation ruled, and many of the omissions of earlier RAAs have been addressed. All parties in the current round of negotiations are to be congratulated.
The ALAC is particularly pleased to see the new sections on Privacy and Proxy registrations; resellers; the Whois Accuracy Program Specification; uniformity of Whois; and a clear, concise simple-language statement of registrant rights and responsibilities.
On a process level, the ALAC wishes to commend ICANN staff for presenting this information in such a way and with multiple views so as to make this very complex set of documents and the differing viewpoints comprehensible.
That being said, there are a number of issues where:
- the ALAC is uncomfortable with the position that ICANN has taken;
- the ALAC believes that additional changes are necessary.
ALAC positions on disputed terms or sections requiring additional change
Issue | ALAC Position |
RAA 3.3.1 – Registrar port 43 access for thick registries | The ALAC does not have a strong position on this, but some members believe that in the absence of a compelling reason from ICANN as to why the port 43 service should be maintained for thick registries, the registrar position is reasonable. Given the current PDP on using a Thick Whois for all registries, the ALAC suggest a middle ground. Specifically, that RAA 3.3.1 require that Registrars provide port 43 access as long as there are Thin registries in existence. If and when there are no longer any Thin registries, Registrars will no longer be required to provide Port 43 access. |
RAA 6.3 – Special Amendment by ICANN without Registrar approval | The ALAC is sympathetic with the rationale for this clause. Specifically, the regular amendment process which can and apparently does take several years, followed by up to five years delay before all registrars are subject to the new RAA is simply too long to address issues that have “substantial and compelling need”. ICANN as the custodian of the domain name system cannot allow problems that undermine the public interest to exist without taking action. Although the ICANN Board already has the authority to enact policy where the stability or security of the DNS is impacted, not all problems that need addressing meet security/stability criteria. Although ICANN is not a formal “regulator” it is in a position where it must have the tools to act in ways similar to a regulator when the public interest is threatened. That being said, the concept of a unilateral change is not one that many in At-Large feel comfortable with. The ALAC urges ICANN and Registrars to find some common ground that will allow the RAA to be changed in the middle of five-year contracts, similar to how it does for formal Consensus Policies (CP), but for issues that are not subject to CP or where the PDP route is simply too long or unable to effectively address the problem. |
RAA 6.7.2 – Definition of Registrar Approval | The ALAC has no strong feelings on whether the proposed rules are reasonable or not. |
Whois Accuracy Program Specification 1, 2, 4 – Registrant identification and contact information | The ALAC supports the ICANN position of using all available information in addressing Whois Accuracy, not solely that which is in the current Whois record. |
Whois Accuracy Program Specification 1e – Information availability | The ALAC is unsure of the subtle difference in meaning between “made available” and “readily available”. If the issue being addressed by the Registrars is a matter of cost or effort required to avail oneself of the information, that should be made much clearer and not rely on the vague term “readily” which is too subject to varying definitions. |
Whois Accuracy Program Specification 5 – Whois inaccuracy remedy | The ALAC believes that the start of this section is too vague. In particular, the word “occurrence” is undefined subject to misinterpretation. The ALAC suggests replacing the beginning of the sentence with “Upon a validated report or discovery of a…”, or alternately, "Upon learning of a...". |
Whois Accuracy Program Specification 8 – Expert Working Group | The Rational for the Board resolution creating the Expert Working Group said “Directing the President and CEO to launch a new effort focused on the purpose and provision of gTLD directory services, to serve as the foundation of an upcoming Board-initiated GNSO PDP. The outcomes of this work should act as guidance to the Issue Report that will be presented as part of the GNSO's policy development work; as a result, the Issues Report is not expected to be produced until such time as the President and CEO determines that his work has progressed to a point that it can serve as a basis of work within the PDP. ” From this, it is clear that the intent was that the Expert Working Group’s conclusions be funneled into a PDP, and it seems premature to have the have the RAA use the Special Amendment process without at least starting the PDP. It would be reasonable to allow the Special Amendment process (or what may replace it in light out the earlier comments) to be used when and if it is apparent that the PDP was not progressing with a reasonable chance of a suitable outcome. |
Consensus Policies 1.2.4 – Taking into account use of domain name | Although the ALAC understand the possible difficulty of having a registrar analyse the usage of a particular domain, one cannot totally ignore such usage either. Any policy that includes the requirement to factor in use of a domain name may be difficult to craft so that it can be effective, but the RAA should not preclude such efforts. |
Consensus Policies 1.3.4 – Details of accuracy and up-to-date specification | It is unclear what the effect would be of the Registrar request to omit the detailed list of issues that are subject to Consensus/Special Policy. If the omission implies that such issues would be out-of-bounds for future policy, the ALAC does not agree. |
Data Retention Specification 1.1.8 – Card-on-File | The impact of this change is unclear. If it is referring to credit card information where a registrar or client choses to not have the registrar save the card number for future use, the issue is a difficult one. The ALAC understands the benefit of maintaining such information for forensic purposes, but at the same time believes strongly that a consumer should be able to require that such information not be stored and therefore subject to hacking and theft. |
Data Retention Specification 2 – Trigger for exemptions | The ALAC supports the Registrar position of allowing a contracted party to comply with local law before they are under investigation or cited. Although this puts a larger burden on ICANN to validate the claim, it is a reasonable request. This is particularly true in the case of a new entry into the field (something that ICANN desperately needs in many parts of the world) where it is completely unreasonable to expect an entity to invest in a new business that will implicitly be violating existing law when it starts. |
FIRST DRAFT SUBMITTED
DRAFT STATEMENT in PDF Format
ALAC Statement on the RAA as posted 7 March 2013
**DRAFT** 28 March 2013, slight addition on 30 March (see comment below)
The ALAC is generally supportive of the RAA and associated specifications as posted for comment. Moreover, the ALAC is generally in agreement with ICANN on the issues where ICANN and Registrars disagree.
The proposed RAA is much better than its predecessor. It provides clarity where previously obscurity and even obfuscation ruled, and many of the omissions of earlier RAAs have been addressed. All parties in the current round of negotiations are to be congratulated.
The ALAC is particularly pleased to see the new sections on Privacy and Proxy registrations; resellers; the Whois Accuracy Program Specification; uniformity of Whois; and a clear, concise simple-language statement of registrant rights and responsibilities.
On a process level, the ALAC wishes to commend ICANN staff for presenting this information in such a way and with multiple views so as to make this very complex set of documents and the differing viewpoints comprehensible.
That being said, there are a number of issues where:
- the ALAC is uncomfortable with the position that ICANN has taken;
- the ALAC believes that additional changes are necessary.
ALAC positions on disputed terms or sections requiring additional change
Issue | ALAC Position |
RAA 3.3.1 – Registrar port 43 access for thick registries | The ALAC does not have a strong position on this, but some members believe that in the absence of a compelling reason from ICANN as to why the port 43 service should be maintained for thick registries, the registrar position is reasonable. |
RAA 6.3 – Special Amendment by ICANN without Registrar approval | The ALAC is sympathetic with the rationale for this clause. Specifically, the regular amendment process which can and apparently does take several years, followed by up to five years delay before all registrars are subject to the new RAA is simply too long to address issues that have “substantial and compelling need”. ICANN as the custodian of the domain name system cannot allow problems that undermine the public interest to exist without taking action. Although the ICANN Board already has the authority to enact policy where the stability or security of the DNS is impacted, not all problems that need addressing meet security/stability criteria.
Although ICANN is not a formal “regulator” it is in a position where it must have the tools to act in ways similar to a regulator when the public interest is threatened.
That being said, the concept of a unilateral change is not one that many in At-Large feel comfortable with. The ALAC urges ICANN and Registrars to find some common ground that will allow the RAA to be changed in the middle of five-year contracts, similar to how it does for formal Consensus Policies (CP), but for issues that are not subject to CP or where the PDP route is simply too long or unable to effectively address the problem. |
RAA 6.7.2 – Definition of Registrar Approval | The LAC has no strong feelings on whether the proposed rules are reasonable or not. |
Whois Accuracy Program Specification 1, 2, 4 –Registrant identification and contact information | The ALAC supports the ICANN position of using all available information in addressing Whois Accuracy, not solely that which is in the current Whois record. |
Whois Accuracy Program Specification 1e –Information availability | The ALAC is unsure of the subtle difference in meaning between “made available” and “readily available”. If the issue being addressed by the Registrars is a matter of cost or effort required to avail oneself of the information, that should be made much clearer and not rely on the vague term “readily” which is too subject to varying definitions. |
Whois Accuracy Program Specification 5 – Whois inaccuracy remedy | The ALAC believes that the start of this section is too vague. In particular, the word “occurrence” is undefined subject to misinterpretation. The ALAC suggests replacing the beginning of the sentence with “Upon a validated report or discovery of a…” |
Whois Accuracy Program Specification 8 – Expert Working Group | The Rational for the Board resolution creating the Expert Working Group said “Directing the President and CEO to launch a new effort focused on the purpose and provision of gTLD directory services, to serve as the foundation of an upcoming Board-initiated GNSO PDP. The outcomes of this work should act as guidance to the Issue Report that will be presented as part of the GNSO's policy development work; as a result, the Issues Report is not expected to be produced until such time as the President and CEO determines that his work has progressed to a point that it can serve as a basis of work within the PDP. ”
From this, it is clear that the intent was that the Expert Working Group’s conclusions be funneled into a PDP, and it seems premature to have the have the RAA use the Special Amendment process without at least starting the PDP. It would be reasonable to allow the Special Amendment process (or what may replace it in light out the earlier comments) to be used when and if it is apparent that the PDP was not progressing with a reasonable chance of a suitable outcome. |
Consensus Policies 1.2.4 – Taking into account use of domain name | Although the ALAC understand the possible difficulty of having a registrar analyse the usage of a particular domain, one cannot totally ignore such usage either. Any policy that includes the requirement to factor in use of a domain name may be difficult to craft so that it can be effective, but the RAA should not preclude such efforts. |
Consensus Policies 1.3.4 – Details of accuracy and up-to-date specification | It is unclear what the effect would be of the Registrar request to omit the detailed list of issues that are subject to Consensus/Special Policy. If the omission implies that such issues would be out-of-bounds for future policy, the ALAC does not agree. |
Data Retention Specification 1.1.8 – Card-on-File | The impact of this change is unclear. If it is referring to credit card information where a registrar or client choses to not have the registrar save the card number for future use, the issue is a difficult one. The ALAC understands the benefit of maintaining such information for forensic purposes, but at the same time believes strongly that a consumer should be able to require that such information not be stored and therefore subject to hacking and theft. |
Data Retention Specification 2 – Trigger for exemptions | The ALAC supports the Registrar position of allowing a contracted party to comply with local law before they are under investigation or cited. Although this puts a larger burden on ICANN to validate the claim, it is a reasonable request. This is particularly true in the case of a new entry into the field (something that ICANN desperately needs in many parts of the world) where it is completely unreasonable to expect an entity to invest in a new business that will implicitly be violating existing law when it starts. |
