- ALAC - lists.icann.org

ERRP Statement
by Alan Greenberg Nov. 29, 2012

Nov. 29, 2012

I have finalized the ERRP statement wording in https://community.icann.org/x/J4Q3Ag. The two changes are: 1. Including the option of other forms of regarding in addition to simply keeping paragraphs 4.1.2 and 4.2.3. This is in conjunction with a post I will be making suggesting that in the PEDNR Recomendation, if given this new knowledge, we might have replaced "If the Registrar operates a website for registration or renewal," to "If a website is operated for registration or renewal,". 2. Adding one final sentence as suggested by Holly giving the broader picture that all registrants dealing with resellers should be given the full complements of rights under the RAA. Alan

1 0

Letter from GAC to GNSO on protection of IOC, RCRC, and IGOs
by Alan Greenberg Nov. 29, 2012

Nov. 29, 2012

I've lost track whther this has been sent to the ALAC list yet (I did see it on a skype chat). <https://gacweb.icann.org/download/attachments/4817665/GAC_GNSOCouncil_20121…>https://gacweb.icann.org/download/attachments/4817665/GAC_GNSOCouncil_20121… Alan

1 0

Fwd: [council] Update from the New gTLD Program Committee
by Alan Greenberg Nov. 28, 2012

Nov. 28, 2012

I think that what this is saying is the Board New gTLD Program Committee on Monday approved temporary reservations for RC, IOC and some unknown subset of IGOs. This would make the resubmitted GNSO motion regarding RC/IOC no longer relevant. I am once again troubled that even after the fact, there is no public knowledge of important Board activities taking place - See http://www.icann.org/en/groups/board/meetings. The last meeting posted is that of the Board on Nov 8. Alan >From: Jonathan Robinson <jonathan.robinson(a)ipracon.com> >To: <council(a)gnso.icann.org> >Subject: [council] Update from the New gTLD Program Committee >Date: Wed, 28 Nov 2012 10:50:16 +0000 >Thread-Index: Ac3NUmnnhSOKAw26S0eLreaaNZM8VQ== >Sender: <owner-council(a)gnso.icann.org> > >All, > >Cherine Chalaby, Chair of the New gTLD Program Committee, has asked >me to forward to you, a letter providing an update on their most >recent (26 November 2012) meeting. > >I have also attached an information update I provided to the New >gTLD Program Committee immediately ahead of their 26 November meeting. > >Jonathan

1 0

Followup meeting on TMCH issues
by Alan Greenberg Nov. 27, 2012

Nov. 27, 2012

Evan and I attended a follow-on teleconference on the TMCH issues today. The following note is written in the first person, but has the full support or Evan. The first part was on the progress related to the negotiation of contracts with Deloitte who will perform the TM validation process and deal with TM holders and IBM who will operate the Clearinghouse and interface with registrars and registries. The contract with Deloitte is close to finalized. The price for registering a single trademark will be $150 (with some variations due to currencies and such) and there will be substantive discounts for multi-year registrations and for bult registrations. ICANN will have access to Deloitte costs and revenue figures and the right to audit Deloitte, all to ensure that their profit margins are kept reasonable (and specifically a contractual profit cap). Although Deloitte has exclusivity until after the first 10 sunrises (ensuring that the protocols and TMCH are functioning well), after that point, ICANN could invite other applicants to play a similar role - a marked change from the original plans. The contract with IBM should be complete within a week or so. As already noted, ICANN will retain all use rights to the data in the TMCH, so although IBM will be able to market other services, they can only do so with the express permission of ICANN. Similarly, ICANN can offer the data to other parties for competing services (all subject to whatever the TM holders agree to when they deposit their information in the CH). Although the details of the "strawman" proposal are not yet agreed to, both contractors have agreed that what ever is there (presumably based on what ins in the current strawman), the contracts already will include that. These could not have been an easy contracts to negotiate, and are the most rational from an ICANN and user standpoint that I have ever seen at ICANN. To make it clear, I am impressed. On the strawman proposal, Fadi divided the issues into three sections: 1. Adding a 30 day "announcement period before the formal 30 day sunrise. 2. a) Extending the 60 TM Claims period to 90 days, and b) tacking on a new, for-fee TM Claims process for 6-12 months (to be decided) with a lighter, less legalistic notice and no requirement to acknowledge receipt. 3. All up to 50 additional character strings associated with a TM to be entered into the TMCH (for a fee). The names would typically be typos or the TM plus related strings (products or services associate with the mark). Following extensive staff discussions, the following Implementation vs Policy recommendations are being made (along with my and Evan's take on them) 1. The original policy was silent on sunrise timing, and certainly did not either mention or prohibit a prior announcement period. This is deemed to be implementation. Comment: No argument at all. I did point out that despite this new 30 day period, between now and the first sunrise, ICANN has a real need to get out there and let TM holders know this is coming. 2. Both the extension of 60 to 90 days and the addition of the new lighter TM Claims process were deemed to be implementation. Comment: There was little discussion about the first part, but much more about the second. I for one was rather surprised as were a number of others. Fadi said that there was a lot of discussion on this point, and he believes that their rationale, which will be made available very shortly will explain why. Regardless of the implementation vs policy issue, this extension of TM Claims is something that the ALAC supported in its minority report to the STI, and the change to a lighter form of notice should adequately address the concerns that the ALAC did have about such extension. I did point out that it was important for the community to be involved in wording this new notice. 3. The additional of "related" strings was deemed to be policy. Only strings that have been the subject of UDRP or Court decisions would be allow (and specifically not URS). Comment: No disagreement here. Fadi will be writing to the GNSO to tell them that they need to offer guidance on this. The TM folks on the call took the opportunity to raise the issue of blocking (or making very difficult) registration on marks and marks+related-strings that have been found to have been abused in the past. Fadi was adamant that such a process was not something that he could imagine approving in a process like the current one. I added that it was sufficiently counter to other decisions that have been made in the past that it would need to be the result of substantive community-based policy discussion. The TM folks did not seem please with this position and we may want to explicitly support Fadi on this one. On the substance of the blocking proposal, At-Large has traditionally been sympathetic to the needs/desires of the TM holders. Although At-Large has a keen interest in Registrant rights, when they may conflict with User issues, we have tended to side with the needs of Users. In this case, the registrations that the TM owners are worried about tend to be used for monetized pages, phishing, deceptive web site or out-and-out fraud. In all of these cases, fighting such uses is generally pro-user. So we are not necessarily completely against the concept. But it would need to be implemented in such a way as to not unreasonably interfere with valid registrations. To date, none of the proposed implementations have come anywhere near this, and they specifically all have tended to be "block until the prospective registrant can demonstrate that they have a legitimate need" - which has a very "guilty until proven innocent" tone to it and with the demonstration being a slow and possibly expensive process. Alan Alan

3 3

Expired Registration Renewal Policy
by Alan Greenberg Nov. 27, 2012

Nov. 27, 2012

Also posted as a comment to https://community.icann.org/x/J4Q3Ag. As you know the Post Expiration Domain Name Recovery (PEDNR) PDP was approved by the Board last year and the resultant Policy (now called the Expired Registration Recovery Policy - ERRP) was posted for comment. The PDP recommended that registrars who operate web site for registration must post their renewal fees and state what method they will use to contact registrants. The recommendation was silent regarding resellers because it was the belief that registrars, in honoring all of the terms of their contract, would require resellers to post this information as well. Although it was not clear why at the time, ICANN staff working on the resultant changes to the RAA added very welcome wording explicitly requiring that registrars require resellers to post this information as well. The proposed policy can be found at <http://www.icann.org/en/resources/registrars/consensus-policies/errp/draft-…>http://www.icann.org/en/resources/registrars/consensus-policies/errp/draft-… and the sections in question are paragraphs 4.1.2 and 4.2.3. There were no negative comments about this in the public comments which were due to close on Nov. 11th. Staff extended the comment period for one more week, and had explicitly called attention to the changes on the Implementation Review Group mailing list and explicitly asking for comments to be posted on this. Michele Neylon, the registrar who was on the Implementation Review Group submitted a statement to the ERRP Comment saying that the proposed language about resellers was debated at length by the PDP WG and the final decision was to not include such language in the recommendation. That is factually correct and indeed the report made reference to the fact that there was an explicit decision to not include it. His statement can be found at <http://forum.icann.org/lists/draft-errp-policy/msg00001.html>http://forum.icann.org/lists/draft-errp-policy/msg00001.html. The ICANN Registrar Relations staff person who I had been working with was unavailable, so I asked compliance whether that was how they saw this as well. The reply was direct and clear that this was not how they interpreted the RAA terms and that the web posting provisions would not apply to resellers unless the explicit. The exchange is appending to this message. I propose the following: 1. Under my own name but as former Chair of the PEDNR WG and a member of the Implementation Review Team, I will post the statement from Compliance that without the explicit reseller language, that the new Policy will not benefit all Registrants, but only those who deal directly with Registrars, and based on my understanding, that was not the intent of the WG. 2. ALAC should post a statement supporting the need to keep the explicit reseller language. This statement may need to be altered if registrars in the interim post a message agreeing to keep the language. Draft Statement The PEDNR PDP recommended that information about renewal fees and how a registrar will contact a registrant should be readily made available on the registrar web site (Rec. 5 & 6). It was the clear intent of the recommendations that this apply to ALL registrants. Paragraphs 4.1 and 4.2 of the ERRP (http://www.icann.org/en/resources/registrars/consensus-policies/errp/draft-…) require, among other things, that if a registrar operates a web site, certain information must be clearly displayed there. Paragraphs 4.1.2 and 4.2.3 require that a reseller, if one is used, must similarly display this information. It is the understanding of the ALAC that the belief within the PEDNR WG was that all provisions of the RAA that applied to registrars must be enforced by registrars on resellers (for those who use them). Since that has now proven to be false (reference to Greenberg post) it is imperative that sections 4.1.2 and 4.2.3 of the proposed ERRP not be omitted. Without these two paragraphs, there is no obligation for a registrar to ensure that a reseller displays this information and a significant percentage of registrants, those who deal with resellers, may be deprived of this information. The access to this information that the PDP was attempting to ensure is no longer guaranteed, and the registrar, by subcontracting services to a reseller, has effectively been relieved from fulfilling these RAA obligations. This calls into question the value of the immense time and energy that the community puts into developing PDP Consensus Policy Recommendations and indeed the effectiveness of the entire RAA. =========== Dialogue with Contractual Compliance Alan Greenberg: >A comment has now been made >(http://forum.icann.org/lists/draft-errp-policy/msg00001.html) >speaking against the language in the draft ERRP Policy paragraphs >4.1.2 and 4.2.3 >(http://www.icann.org/en/resources/registrars/consensus-policies/errp/draft-…) > >As a result, the ALAC now needs to decide whether to reply to this, >and if so, what we need to say. > >In order to understand the issue, I would like to know whether ICANN >Contractual Compliance believes that the inclusion of these sections >alters their ability to enforce the intent of the ERRP. > >Specifically, it has been stated repeatedly that all obligations of >a Registrar are unchanged if they decide to sub-contract marketing >to a reseller. In this case, I take this to mean that the obligation >to have certain information on the Registrar's web site also >includes the reseller's website if that is the Registrant point-of-contact. > >That would imply that what is explicit in 4.1.2 and 4.2.3 is >applicable whether these statement are there or not, and their >presence simply serves to remind Registrars of their obligations. > >Can you please confirm if that is a correct interpretation, or if >not, how you view it. ICANN Contractual Compliance: >ICANN does not have the same interpretation. > >The reseller obligations as stated in section 3.12.2 of the 2009 RAA >focus on the registration agreement where, if a registrar has an >agreement with its resellers, the agreement must require the >reseller to include all registration agreement provisions and >notices required by the ICANN Registrar Accreditation Agreement and >any ICANN Consensus Policies (such as the information identified in >4.1.1 and 4.2.2 of the proposed ERRP). The reseller obligations >within the 2009 RAA do not include obligations on registrars to >require the posting of information such as that within the proposed >ERRP Sections 4.1.2 and 4.2.3 on reseller websites. > >Under the contracts we have in place today, the reseller website >posting obligations in the proposed ERRP section 4.1.2 and 4.2.3 >would only be enforced if the language is included within the ERRP.

1 0

Preliminary Issue Report on the Inter-Registrar Transfer Policy (IRTP) Part D
by Alan Greenberg Nov. 27, 2012

Nov. 27, 2012

I was asked for an opinion on whether an ALAC statement is necessary on the <https://community.icann.org/display/alacpolicydev/At-Large+Preliminary+Issu…>Preliminary Issue Report on the Inter-Registrar Transfer Policy (IRTP) Part D. The short answer is that I do not believe that a statement is required, but I would appreciate a "sense of the ALAC" that this PDP should be initiated. IRTP-D is the last of a set of PDP's to review and possibly update various aspects of the Inter-Registrar transfer Policy (IRTP). IRTP-D consideres: a) Whether reporting requirements for registries and dispute providers should be developed, in order to make precedent and trend information available to the community and allow reference to past cases in dispute submissions; b) Whether additional provisions should be included in the TDRP (Transfer Dispute Resolution Policy) on how to handle disputes when multiple transfers have occurred; c) Whether dispute options for registrants should be developed and implemented as part of the policy (registrants currently depend on registrars to initiate a dispute on their behalf); d) Whether requirements or best practices should be put into place for registrars to make information on transfer dispute resolution options available to registrants; e) Whether existing penalties for policy violations are sufficient or if additional provisions/penalties for specific violations should be added into the policy; f) Whether the universal adoption and implementation of EPP AuthInfo codes has eliminated the need of FOAs (Forms of Authorization). This Public Comment is an opportunity to identify errors or omissions in the Preliminary Issue Report, and to provide support for initiating the PDP. O know of no specific errors or omissions. Although I support the PDP going forward, given the long history which got us to this stage, I am not expecting much opposition so I do not feel that a written comment is worth the effort. The PDP does address a number of issues that could benefit registrants and for that reason I do believe that it should go ahead. If the ALAC agrees, I would like to carry that message forward. I would also strongly advise that there be At-Large representatives on the resultant WG. Alan

1 0

The sales case for defensive registrations
by Evan Leibovitch Nov. 22, 2012

Nov. 22, 2012

I just received an unsolicited email that some of you may find interesting. Due to non-ICANN related work, I own a domain related to ebooks. Some domainer -- or its agent -- sent me a solicitation to acquire a similar domain. Obviously my WHOIS info was culled for this, but that doesn't particularly bother me. What is interesting to read is the sale pitch that pushes defensive registrations and says that even if you own a trademark it doesn't really matter. Quotes of note: *Q:But I already own a similar domain, why do I need another one?* * * *A: The answer is pretty simple, you will get more exposure for your business for the least amount of money. Search engines file your page contents within one domain name. If you have multiple domains, this multiplies the chance of having a surfer click on the link to your website.* *Q:But my domain name and business are trademarked..* * * *A: This does not really prevent other people from using unregistered versions of your trademark for other legal or illegal reasons. A good example is Nissan.com, a trademark just for your branch in the industry and quite often just for your region of the world. Defensive registering will help protect your brand and business.* I have zero interest in the domain, if anyone else wants *stud-ebooks.com*you're welcome to it http://ourbestnames.net/acquire/hgag/WkaM3hn6T7 -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56

1 0

Fwd: [council] FW: URS update
by Alan Greenberg Nov. 22, 2012

Nov. 22, 2012

FYI. Alan >From: Olof Nordling [mailto:olof.nordling@icann.org] >Sent: 22 November 2012 10:26 >To: Jonathan Robinson (jonathan.robinson(a)ipracon.com) >Subject: URS update > >Dear Jonathan, > >The deadline for responses to the URS RFI has passed and I'm happy >to inform you that we have received several responses which we are >now evaluating. Moreover, my first impression is that the situation >looks quite promising, both in terms of adherence to the URS text >and regarding the target fee. This also means that there is less of >an urgency than I previously thought to convene a drafting team >(and I'm glad to have been proven wrong in that regard!). There may >still be details where such a drafting team can provide useful >guidance and I will get back to you with further updates on this and >other URS matters as we advance with the evaluations. > >Very best regards > >Olof

2 1

Google launches "Fight the ITU/WCIT" website
by Evan Leibovitch Nov. 20, 2012

Nov. 20, 2012

https://www.google.com/intl/en/takeaction/ Also: https://www.google.com/intl/fr/takeaction/ https://www.google.com/intl/es/takeaction/ https://www.google.com/intl/ar/takeaction/ https://www.google.com/intl/zh-CN/takeaction/ https://www.google.com/intl/pt-BR/takeaction/ https://www.google.com/intl/ru/takeaction/ And a number of others... -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56

1 0

Board WHOIS resolution and Board Briefing Document
by Alan Greenberg Nov. 20, 2012

Nov. 20, 2012

(Thanks to Bruce Tonkin) WHOIS Policy Review Team Report Whereas, the WHOIS Policy Review Team Report was submitted to the Board on 11 May 2012 and was the subject of extensive public comment and community discussion; Whereas, the Review Team's work has encouraged the Board and community to re-examine the fundamental purpose and objectives of collecting, maintaining and providing access to gTLD registration data, has inspired renewed and new efforts to enforce current WHOIS policy and contractual conditions, and has served as a catalyst for launching a new approach to long-standing directory services challenges; Resolved (2012.11.08.01), the Board directs the CEO to launch a new effort to redefine the purpose of collecting, maintaining and providing access to gTLD registration data, and consider safeguards for protecting data, as a foundation for new gTLD policy and contractual negotiations, as appropriate (as detailed in the 1 November 2012 Board paper entitled, "Action Plan to Address WHOIS Policy Review Team Report Recommendations"-ICANN Board Submission Number 2012-11-08-01 [PDF, 266 KB]), and hereby directs preparation of an Issue Report on the purpose of collecting and maintaining gTLD registration data, and on solutions to improve accuracy and access to gTLD registration data, as part of a Board-initiated GNSO policy development process; Resolved (2012.11.08.02), the Board directs the CEO to continue to fully enforce existing consensus policy and contractual conditions relating to the collection, access and accuracy of gTLD registration data (referred to as gTLD WHOIS data), and increase efforts to communicate, conduct outreach on, and ensure compliance with existing policy and conditions relating to WHOIS (as detailed in the 1 November 2012 Summary of the Board Action entitled, "WHOIS Policy Review Team Report Recommendations"). Resolved (2012.11.08.03), pursuant to Article III, Section 5.4 of the Bylaws, the Board directs that the contents of this resolution and rationale shall not be made publicly available until 19 November 2012. Rationale for Resolutions 2012.11.08.01 - 2012.11.08.02 The Affirmation of Commitments (AoC) between ICANN and the U.S. Department of Commerce commits ICANN to enforcing its existing policy relating to WHOIS (subject to applicable laws), which "requires that ICANN implement measures to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information." The AoC obligates ICANN to organize no less frequently than every three years a community review of WHOIS policy and its implementation to assess the extent to which WHOIS policy is effective and its implementation meets the legitimate needs of law enforcement and promotes consumer trust. The AoC further commits ICANN's Board to publish for public comment the report submitted by the Review Team, and to take action on the report within six months of its submission. The Team's volunteer members were appointed by ICANN's CEO and the GAC Chair, per the AoC requirements, and reflected the broad Internet community's interests in WHOIS policy. For 18 months, the Team conducted fact-finding, including meetings with ICANN's relevant Supporting Organizations and Advisory Committees, members of the broader Internet community, and other interested parties, and issued a draft report for public comment before submitting its Final Report to the Board on 11 May 2012. The Report was posted for two months of public comment and the Board requested input from ICANN's Supporting Organizations and Advisory Committees. Community discussion and input on the Report continued through the ICANN Toronto meeting in October 2012. The GAC and ALAC endorsed the WHOIS review report, SSAC provided a response in SAC055 (http://www.icann.org/en/groups/ssac/documents/sac-055-en.pdf) and the GNSO provided a response by constituency (http://gnso.icann.org/en/correspondence/robinson-to-icann-board-07nov12-en.… [PDF, 377 KB]). There is general agreement on the objective of strengthening the enforcement of existing consensus policies and contracts and the WHOIS Review Team Report provides many relevant recommendations to that effect. However, both the WHOIS Review Team Report and the SSAC comments highlighted the limits of the current framework for gTLD directory services and the need to move beyond the present contractual provisions. The WHOIS Review Team for instance clearly stated that "the current system is broken and needs to be repaired." Likewise, the SSAC report stated that "the foundational problem facing all 'WHOIS' discussions is understanding the purpose of domain name registration data", that "there is a critical need for a policy defining the purpose of collecting and maintaining registration data" and suggested that "the formation of a properly authorized committee to drive solutions to these questions first, and to then derive a universal policy from the answers, is the appropriate sequence of steps to address the WHOIS Review Team's report ." Indeed, the WHOIS protocol is over 25 years old (the current version is documented in RFC3912 dated September 2004, and the original version is documented in RFC812 dated March 1982). Furthermore, ICANN's requirements for domain name registration data collection, access and accuracy for gTLD registries and registrars are largely unchanged after more than 12 years of GNSO task forces, working groups, workshops, surveys and studies. Concerns of access, accuracy, privacy, obsolescence of protocols in an evolving name space, and costs to change remain unresolved. In this context, taking into account these inputs and community concerns, the Board has determined that a broad and responsive action is required and has decided to implement a two-pronged approach. Accordingly, the Board is simultaneously: 1.Directing the President and CEO to continue to fully enforce existing consensus policy and contractual conditions as well as to increase efforts to communicate, conduct outreach on, and ensure compliance with such existing policy and conditions. 2.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. On both aspects, additional information is contained in the document, "Action Plan to Address WHOIS Policy Review Team Report Recommendations"-ICANN Board Submission Number 2012-11-08-01" (http://www.icann.org/en/groups/board/documents/briefing-materials-1-08nov12… [PDF, 266 KB]). As part of the work of the President and CEO to ensure continued compliance with existing policy and conditions, the President and CEO has moved the Compliance Department to report directly to the President and CEO (http://www.icann.org/en/news/announcements/announcement-14sep12-en.htm) and the Board granted financial authorization to establish a Contractual Compliance Audit Program through an independent Service Provider (http://www.icann.org/en/groups/board/documents/resolutions-03oct12-en.htm#1…) Furthermore, appropriate liaison will be established with the ongoing work undertaken in the IETF WG on the Web Extensible Internet Registration Data Service (WEIRDS) Protocol to ensure coherence. The Board strongly feels that taking this two-pronged approach is essential to fulfill ICANN's responsibility to act in the global public interest. The initiation of a focused work on Whois is expected to have an impact on financial resources as the research and work progresses. If the resource needs are greater than the amounts currently budgeted to perform work on Whois-related issues, the President and CEO will bring any additional resource needs to the Board Finance Committee for consideration, in line with existing contingency fund request practices. This action is not expected to have an immediate impact on the security, stability or resiliency of the DNS, though the outcomes of this work may result in positive impacts. This is an Organizational Administrative Function of the Board for which the Board received public comment, at http://www.icann.org/en/news/public-comment/whois-rt-final-report-11may12-e….

1 0