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
28.03.2013Proposed 2013 RAA Posted for CommentAdopted
14Y, 0N, 0A 
Alan Greenberg (NARALO)28.03.201309.04.2013n/a11.04.2013
(ALAC Meeting in Beijing) 
n/a11.04.201311.04.2013Samantha Eisner
samantha.eisner@icann.org
AL/ALAC/ST/0413/3
Comment / Reply Periods (*)
Comment Open Date: 
7 March 2013
Comment Close Date: 
28 March 2013 - 23:59 UTC
Reply Open Date: 
29 March 2013
Reply Close Date: 
19 April 2013 - 23:59 UTC
Important Information Links
Brief Overview
Originating Organization: 
ICANN
Categories/Tags: 
  • Contracted Party Agreements
Purpose (Brief): 

ICANN is seeking public comments on a Proposed 2013 Registrar Accreditation Agreement (RAA), particularly on areas where ICANN and the Registrar Negotiating Team have not been able to reach agreement in principle. This represents the first time in the nearly 18 months of negotiations that community comment is formally sought on this document.

Current Status: 

ICANN and the Registrar Negotiating Team commenced negotiation on amendments to the RAA in October 2011. While the documents posted today show many areas of agreement, there are differences between theICANN and Registrar positions are highlighted. In addition, further discussion is still ongoing regarding some of the specifications to the agreement.

Next Steps: 

After review of the comment received, the proposed 2013 RAA will be reviewed to determine if further changes are warranted. In addition, ICANN and the Registrar NT are likely to continue discussions regarding the areas where the specifications remain open. The ultimate goal is to have a 2013 RAA completed and approved in the near future.

Staff Contact: 
Samantha Eisner, Senior Counsel
Detailed Information
Section I: Description, Explanation, and Purpose: 

After nearly 18 months of negotiations, ICANN is posting a new version of the proposed 2013 Registrar Accreditation Agreement (RAA) for public comment.

The Registrar Negotiating Team (NT) has continued to engage in good faith negotiations to understand ICANN's perspective with respect to the outstanding issues, and to share the often divergent positions within the Registrar Stakeholder Group. Recently, additional revisions were proposed by ICANN's Negotiating Team stemming from the call by ICANN's CEO, Fadi Chehadé, to work to improve the image of the domain industry and to protect registrants through a further updated contractual framework. The Registrar NT considered each of these new issues, and worked towards finding solutions where appropriate. The RAA posted today reflects hard-fought concessions on many of key issues raised throughout the negotiations, and highlights issues remaining in order for the final 2013 RAA agreement to be reached.

Throughout the RAA and its Specifications, there are portions where two versions of draft text appear side by side. These highlight areas whereICANN and the Registrars have not been able to reach agreement in principle on an issue, therefore both positions are provided for comment. Unless otherwise noted, the remainder of the document reflects agreements in principle among ICANN and the Registrar NT.

A fuller discussion of the status of negotiations and areas of difference is available in ICANN's RAA Posting Memorandum [PDF, 66 KB].

Section II: Background: 

The current round of negotiations over the RAA began in October 2011. ICANN and the Registrar Negotiation Team have presented updates to the community at each of ICANN's public meetings since that time. Information on the history of the negotiations, including previously released documentation, is available at the community wiki athttps://community.icann.org/display/RAA/Negotiations+Between+ICANN+and+Registrars+to+Amend+the+Registrar+Accreditation+Agreement. This includes the group of documents posted in June 2012, which demonstrated the progress to date in the negotiations.

Section III: Document and Resource Links: 

There are multiple documents for review as part of this posting. The new RAA is anticipated to be a base document with a series of specifications attached. This posting includes all documents that are currently anticipated to be part of the 2013 a. As noted above, a fuller discussion of the status of negotiations and areas of difference is available in ICANN's RAA Posting Memorandum [PDF, 66 KB].

The base RAA documents:

The Specifications and Addendums:

For the Consensus and Temporary Policy Specification, the Data Retention Specification, and the Whois Accuracy Program Specification, each is available in annotated format to show where differences remain with the registrars, as well as redlines showing the differences in the documents from the 2012 posting.

For the remaining specifications to the RAA, the versions below are provided as ICANN's latest proposal. The Registrar Negotiation Team is still considering each of these specifications:

Section IV: Additional Information: 
None

(*) 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.

 

 


  • No labels

17 Comments

  1. 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)


    1.  REGISTRAR ACCREDITATION AGREEMENT (RAA)

    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:

    • that there is data in all the Whois information fields,
    • that it is in proper format for the relevant country or territory,
    • that email addresses, and telephone numbers and postal addresses are in the proper format.
    • Postal addresses must also be consistent, but the point of disagreement between ICANN and the registrars is whether information for postal validation is only where 'made available to registrars', or is simply 'readily available'.
    • Verification must be either by calling the party – who must response with a unique code, or by SMS with response.

    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.

     

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

  2. I would like to see the following:

    1. Explicitly endorse the RDDS Specification [Section 3.2.1.2 et. al.] and additional data elements included; Registrar Abuse Contact data, Reseller data and Domain Status data
    2. Call for harmonisation of RDDS Specs across Registrar and Registry Agreements
    3. Reject the registrar contention with respect to relaxation of public WHOIS access requirements in thin vis-a-vis thick registries [Section 3.3.1],
    4. Endorse the adoption of the WHOIS Accuracy Program Specification [Section 1.25] and explicitly advise accuracy standards for the registrant identification and address data elements
    5. Endorse Privacy and Proxy Accreditation Program and their requirements [Section 3.14.2] and advise addition of a clause that explicitly affirms strict liability of the provider for accuracy of WHOIS data
    6. Endorse and advise an explicit connection of WHOIS Accuracy Program Specs to enforcement actions per Clause 3.7.8 by adding a clause 3.7.9 that binds the registrar to the possible responses to inaccurate WHOIS data as defined in Accuracy Program Specs.
    7. Record the ALAC's disquiet regarding declared unilateral right to adjust contract but limit and spell out the conditions under which this is invoked.

    -Carlton

     

    1. Thanks Carlton. A few comments to ensure that I understand what you are saying.

      1. I don't think there is much new related to RDDS (for those not familiar with the acronym - Registration Data Directory Services - what has generally been called Whois, although I think that the latter term is still used in the RAA (RDDS is used in the new Registry agreements)). BUt yes, endorse those thing you specifically call out.
      2. Not sure how harmonization fits in the current public comment.
      3. Can you explain why. Personally, I cannot really justify registrars having to maintain the port 45 service for data that is coming from the registry. But perhaps I am missing something.
      4. Are you saying standards in addition to what in in thedraft Spec now. If so, exactly what are you asking for?
      5. Can you be explicit (perhaps a sample RAA clause) on what you are asking for?
      6. The accuracy sped is already explicitly cited in 3.7.8 saying that the registrar shall comply with it. What exactly are you asking for in addition to this?
    2. 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

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

    1. Thanks.

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

      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?

      #4: Split the difference between the negotiating parties by explicitly prioritizing accuracy requirements for some elements reasonable people would say 'yeah, that makes sense'.

      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.

      #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."

      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.

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

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

     

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

       

  6. Added reference to being particularly pleased with addition of Whois Accuracy Program Specification.

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

    1. 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?)

      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.

      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.

      Are there any rights/responsibilities associated with the sections still under dispute that you feel should be included?

      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.

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

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

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

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

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