| 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. |
17 Comments
Holly Raiche
I have not made comments on all of the documents that are included as open for comment. I have only looked at the documents that I think directly impact on users. But I'd be delighted if others with a more technical background looked at the other documents for anything that I will have missed.
What is below are my thoughts - not text. But I hope it will held Alan (who has probably gone through the documents with a very fine tooth comb anyway) and others work your way through the documents we are supposed to respond to.
My first thoughts are that we should welcome many of the changes which amount to a significant improvement in the RAA and related documents.
We should also note, though, that most of the RAA changes have already been agreed to, so there would be little or no scope to make further changes. There is more opportunity to influence changes in documents where there are areas of dispute or where the document is still being considered.
My comments on the specific document changes are below: (and in many cases, sincerely ask for ALAC input)
Resellers:
Welcome expanded definition of Reseller (1.22) to cover any entity that participates in the Registrar’s distribution channel for domain name registrations.
Access to Whois
One area where agreement has not been reached is on the access registrars must provide to Whois data. Currently, they must provide access through a port 43 Whois service and an interactive webpage. ICANN wants both avenues of access maintained; what registrars want is to provide both avenues of access only for ‘thin’ registries, and not port 43 access for thick registries. What the registrars are arguing is that the provision of port 43 whois service duplicates a registry provided service and is not ‘meaningfully’ used by third parties.
This would be supported by a new provision (already agreed) that allows a registry operator and registrar operator (3.3.1) to agree on alternative data elements to the Whois elements (3.3.1.1-3.3.1.8) if approved by ICANN.
Comment: The immediate issue is whether we believe port 43 access should be retained. Given that registrars must provide an interactive webpage to the data anyway, which is also held in escrow, I do not believe we are concerned with the registrar’s position.
What the changes seem to envisage is a move away from registrars holding data to registries being the source of data. My issue is that the current requirement on registrars to provide data to registries (3.2.1) list data that is less than the Whois data (3.3.1.1-3.3.1.8) If we move towards the registry as the source of data, the data that must be given to registries must include all of the elements of Whois data (3.3.1.1-3.3.1.8), and not changed to the lesser requirements in 3.2.1.
Privacy/Proxy:
Welcome the new arrangements (3.4) (a two step process) for privacy/proxy accreditation. Until there is a Proxy Accreditation program, Whois information and contact data must be given to ICANN on reasonable notice and request, with reference to applicable national laws on accessing data. This must be in accordance with the Privacy and Proxy Specification. (see below - still being considered by Registrars) ICANN must not disclose such data except as expressly required by law, legal proceedings, specification or policy.
Comment
Query if we are happy with the level of protection for personal information under the interim Specification. Clearly, we should participate in the development of the Proxy Accreditation program.
Registrant as a person
Welcome the new requirement (3.7.7) that the registrant must be a legal person. NB, the requirement is on the registrant. Still, it may lessen the number of Donald Ducks registering??!!
Whois Accuracy – requirement
The requirement for registrar validation/verification of the accuracy of Whois information has been significantly strengthened through the specific requirement (3.7.8) for registrar compliance with the Whois Accuracy Program specification and the specification itself). The missing piece is registrar response to public complaints about inaccurate whois data. (see below)
Registrants Rights & Responsibilities
Registrars must now publish this document on their website.
Comment
This is a good requirement – but before we think it endorse it , we should review what will be in the document
Point of Abuse Contact
We should welcome the new requirement (3.18) for registrars to have an abuse point of contact including an email address and phone number available 24/7, and must review ‘well founded’ reports of illegal activity within 24 hours.
2. WHOIS ACCURACY PROGRAM SPECIFICATION
Validation of data now must happen within 15 days. ICANN wants validation for the elements below for both the Whois information and the corresponding customer account holder contact information. The registrars only want validation for the Whois information. Validation must include:
The Specification also says that when a registrant wilfully provides ‘inaccurate or unreliable’ information, or fails to respond for 15 days to registrar inquiries about the accuracy of contact details, the registrar must either suspend or terminate the registration until the registrar has validation of the information. (again, ICANN wants the requirements to apply to the registrant and, if different, the account holder. Registrars only want the requirements to apply for the registrant.)
Comment: While this amounts to a very significant strengthening of data accuracy verification and compliance, it does not cover situations where members of the public report inaccuracy of the data.
Garth suggests a change of language in the specification to read: Upon the report or discovery of a Registered Name Holder’s wilful provision of inaccurate or unreliable Whois information….
3. REGISTRAR INFORMATION SPECIFICATION
This document is still being considered by registrars. This sets out the basic information that should be supplied by registrars about themselves and their affiliates and resellers to ICANN. We should support this basic information about registrars, affiliates and resellers (and any privacy/proxy services) being available.
4. SPECIFICATION ON PRIVACY AND PROXY REGISTRATIONS
The basic requirements are that privacy/proxy services must only be offered in accordance with the specification, that there must be full disclosure of terms (including circumstances under which information will be revealed and the process followed), having an abuse point of contact available 24/7, and ‘well founded’ reports of illegal activity must be followed up within 24 hours. The contact details must be held in escrow and allegations of malicious conduct, cybersquatting and other illegal activities must be forwarded within 5 business days.
Alan Greenberg
Thanks Holly, Several comments
Access to Whois:
Not important, but the provision for a TLD to use alternate Whois elements was always there. What is new is a change in how it is presented in the RAA.
I don't think there is a problem. the items in 3.2.1 are those that are common to bother thick and thin registries. 3.3.1 includes the other items that may currently reside in just the registrar database (for thin) or both registry and registrar (for thick). What the elements are that a particular registry uses are set out in the registry agreement, so there is no danger that elements considered important to ICANN will disappear at the registry's whim.
Whether the 3.3.1 elements are transferred to the registry depends on thick vs thin.
As an example of differences that may occur, if I remember correctly, for .tel, the name servers are not provided by the registrant to the registrar and on to the registry, but the other way around, they originate with the registry. The RAA must allow this kind of differnet model of what a registry provides, and this these clauses allow for that.
Registrant as a Person
I'm not sure what you are getting at here. The section says that a registrant may be a person or legal entity (with some specific language related to the registrant being the registrar itself).
Whois Accuracy
The substance of the differences between ICANN and the registrars seems to be whether each "registrant" stands alone and is identifiable purely based on what is in Whois, or that information outside of Whois that a registrar has on the client must also be verified and used to long together multiple registrants.
The specific language suggested by Garth is the kind of suggestion that we should be making. Very targeted and specific.
Carlton Samuels
I would like to see the following:
-Carlton
Alan Greenberg
Thanks Carlton. A few comments to ensure that I understand what you are saying.
Michele Neylon
Carlton
I don't understand your position about registrar whois.
Why would a registrar have to run whois servers to send back the data that the registry whois already does?
For example, if you do a look up on icann.org the data you get back comes from the registry NOT the registrar. But at the moment the registrar is expected to also provide the same data via whois.
They cannot proxy back the registry whois.
This is completely illogical, as the data will be identical. Remember the registrar is obliged to send the updates to the registry.
Michele
Carlton Samuels
Hi Alan:
First, following on the conversation on the Ex-Com call, we are agreed that the approach to this statement should be to 'pile on' for one set of views or other. So let's specifically endorse the specific clauses that coincide with the At-Large positions. Where they differ, we should at least reiterate our views and possibly offer some guidance.
Responding now to specifics of your queries:
#2 & #3: VI makes it possible for the Registry operator to be a Registrar simultaneously. It may be that both operations are ring fenced but I think unlikely. Ensuring harmonisation of the RDDS requirements across both domains is not only practical but moots the concerns for asymmetric WHOIS data holdings.
#4: Split the difference between the negotiating parties by explicitly prioritizing accuracy requirements for some elements reasonable people would say 'yeah, that makes sense'.
#5: Even with the Accuracy Specs and some of the process details laid out for the acceptable responses to inaccurate data, some of our brethren are vociferous Clause 3.7.8 does not offer sufficiently unambiguous enforcement covenant. So maybe a Clause 3.7.9 could be. "When inaccurate WHOIS data is confirmed, the Registrar is required to <enumerate the actions>. Failure to act shall be a breach of contract and subject to compliance remedies previously agreed."
-Carlton
Alan Greenberg
Thanks.
On harmonization, for any given TLD, they are harmonized. That is the point of saying the specs in the RAA may need to vary by TLD.
How does this address registrar port 43?
We could do that. I admit it irks me that registrars will often have information that could improve accuracy and yet refuse to be compelled to use it though.
We can suggest something like this, but I cannot see it being accepted. It is already there and repeating it does not make it stronger.
Alan Greenberg
I have posted a first draft. It is not the short and concise statement I envisioned, because as I started to write it, I realized that if the ALAC wanted to impact the outcome, we needed to identify, to the extent possible, WHY we supported or rejected any of the particular sections that are currently in dispute.
I attempted to do this to the best of my ability, with the understanding that in some cases, I simply do not completely understand the motivation for the different positions. In such cases, I just said that. If anyone else understands better than I, please speak up.
Alan
Holly Raiche
Alan's statement - and Michele's input - still ignore one issue. The information that must be supplied by the registrar to the registry is in 3.2.1 - and is LESS than the Whois information that must be made provided by registrants to registrars under 3.3.1.1-3.3.1.8. So the registry does NOT necessarily have all the information about a registrant that must be gathered and made available by the registrar. Specifically, the Whois information includes contact details for the registrant, plus date of registration and expiration - all critical in many circumstances. That data is NOT required to be passed to the registry under 3.2.1 so unless that data - that a registrar must collect - is also required to be passed to the registry, the registry may not hold it. Since we are moving towards a universal requirement for 'thick' registries, the requirement for data to be collected by the registrar should be the same as the data provided by registrars to registries.
This issue is highlighted by my comments above on the new 3.3.1 - registrars and registries can agree on a data set to replace 3.3.1.1-3.3.1.8. That should not be allowed unless the data set provided by registrars under 3.2.1 is expanded to be the full set of information now in 3.3.1.1-3.3.1.8 - the Whois information.
Alan Greenberg
Holly,
Nothing here is changing from the current RAA,
It is my understanding that 3.2.1.6 covers this (any other info required by Registry).
The Registry Agreement give a list of what data the registry must display for each domain. They cannot display it if they don't have it. Since this data may vary from Registry to Registry, it is not listed in the RAA, but the RRA requires it (see 3.7.1 of .org RRA - http://pir.org/pdf/ORG-RRA-3-April-2007-FINAL.pdf).
It is not entirely correct that Registrar and Registries can agree on what needs to be transferred, because ICANN is also a party to the decision. What items a Registry needs to display is set in the Registry agreement. The flexibility is because with varying registration models, the needs may change. Changes related to privacy issues (with the agreement of ICANN) might also change the details.
Alan Greenberg
Added reference to being particularly pleased with addition of Whois Accuracy Program Specification.
Holly Raiche
Another of the issues is the enforceability of 3.8.7. In response to concerns that the expanded wording of the clause plus the Accuracy Specification still does not require a registrar response to a report of inaccurate data, I suggest that section 5 of the Accuracy Specification use the phrase 'upon learning of a Registered Name Holder's...." I think that covers any way in which the registrar becomes aware of inaccurate or unreliable information. While I like Carlton's new clause 3.9.7, it may be easier to have the language of the new specification changed rather than the RAA itself. (or maybe just use Carlton's words, but in the specification?)
My other comment is about the new Registrants' Rights document. The suggested comment is a brief one: viz a clear, concise simple-language statement of registrant rights and responsibilities.
It is clear and concise. But it may not be complete. I think we should welcome the document, but flag that it should be revisited after the other documents are finalised. It may well be that one outcome of the finalisation of all the documents is that additional 'rights' are an outcome - rights which should be reflected in the Rights document.
We may also want to add items. In the last IRTP-D meeting, there was discussion on what to do if a registrar does not initiate a dispute on behalf of a registrant. My suggestion - which seem to be well received - was that we put something in the Registrants' Rights document about what should happen in those circumstances. There may be other issues that should be included as well.
So perhaps our comment is to complement the document - but call for its revision once all of the RAA documents are finalised.
Alan Greenberg
I assume that you mean 3.7.8 since there is no 3.8.7. I don't understand what you are getting at. 3.7.8 plus the Whois Accuracy Program Specification which it explicitly points to must be complied with or this is a breach of the RAA, and the Spec makes explicit that a registrar must disable the name in the absence of the data being corrected.
If I read Carlton's proposal correctly, it repeats what is in the spec, section 5, and then says that if the Registrar does not comply with the RAA it is in breach. Isn't that implicit in any contract?
I will add your alternative wording in the section 5 lead sentence.
Are there any rights/responsibilities associated with the sections still under dispute that you feel should be included?
If something is actively under discussion in a formal PDP, it is generally not subject to staff over-riding (which is what this would be), so I would think that this idea should be pursued through the PDP. The current Registrant Rights document is a list of what is already in the RAA, so it cannot talk about what should happen if it is not alread there (or under discussion in the present RAA negotiations).
Holly Raiche
Sorry - I did mean 3.7.8. And I was responding to the comments that have been made by Garth. The point he is making is about a requirement for registrar response to public input on inaccuracy. So yes - a response is required. The issue Carlton, Garth and I were raising was a response to public input.
As to Registrants Rights fact sheet, I appreciate that it is a list of what is in the RAA. What I have not had time to consider is whether it is a complete list or whether there things that have been left out that would be of concern to registrants. If you (Alan) are satisfied that everything that a registrant should know about what is in the RAA is fully explained in the fact sheet, I'll be happy to drop this issue.
Alan Greenberg
3.7.8 specifies on "notification by any person", so I think that includes public input. I personally believe that the Whois Accuracy Program Specification (WAPS if we are going to continue this dialogue), section 5 leading off with "Upon the occurrence of a..." covers this. However, on yours and Garth's suggestion (modified somewhat by me), we are saying that for clarity this should say "Upon a validated report or discovery of a…" or "Upon learning of a...".
On the Registrants Rights and Responsibilities (RRR), I don't know of anything that is currently disputed that is of sufficient substance to impact the statement. The only issue that affects registrants (presuming they have accurate Whois info) is retention of the card-on-file, and I don't think that it is at the level to be included in this statement. Moreover it is a business practice issue and is quite registrar specific. So no, I don't think there is an issue here. That is not to say the RRR could not be improved. But this is not the window to do that. Let's get it in effect first, and then try to make it better.
Holly Raiche
If Garth is happy with your rewording of section 5, I am.
On the RRR, at this stage, I haven't had time to twarl through to make sure everything is there. If we can look at it as a document that wecan come back to once we can see the totality of what is finally agreed for all the documents, then fine. I'd just hate to close off consideration of it prematurely since it is the one document that is so clearly of user concern.
Alan Greenberg
Garth has not spoken up recently, so don't know. You could try to reach out to him.
On RRR, I do not see the need (although there is desire) to alter in this round. It is unlikely to be re-opened and not where we should be putting our efforts.
We need to choses our battles and focus on things that are both important and can be won.