Page History

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 45 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.