<html><body><span style="font-family:Arial; color:#000000; font-size:10pt;"><div>Seth and Team:<br><br>That's somewhat correct, except that there is no given "term" for the RAA. Registrars are signing and renewing throughout the year, so everyone has a different term remaining.</div><div><br>However, if there were a change to the RAA, registrars would either (a) sign it at the end of their existing term (maximum 5 years) or (b) be incentivized to renew early. Option (b) was fairly effective in promoting adoption of the 2009 RAA, with the incentive being a slight reduction in registration-level fees.</div><div><br></div><div>J.</div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [Rt4-whois] Adopting Specification 4 of the AGB<br>
From: "Seth M Reiss" <<a href="http://seth.reiss@lex-ip.com">seth.reiss@lex-ip.com</a>><br>
Date: Tue, November 22, 2011 10:50 am<br>
To: "'Smith, Bill'" <<a href="http://bill.smith@paypal-inc.com">bill.smith@paypal-inc.com</a>>,<br>
<<a href="mailto:denise.michel@icann.org">denise.michel@icann.org</a>><br>
Cc: <a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><br>
<br>
I am wondering if the distinction being made and perhaps missed here is that<br>
changes to the RAA can be made mid-stream through the PDP but otherwise, a<br>
change can only be implemented when the term of a given RAA runs out and is<br>
up for renewal. In other words, ICANN cannot force an amendment on a<br>
registrar until that registrar's RAA is up for renewal, but a registrar's<br>
obligations under the contract can be amended through a PDP because the<br>
current RAA states that it may.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:rt4-whois-bounces@icann.org">rt4-whois-bounces@icann.org</a> [<a href="mailto:rt4-whois-bounces@icann.org">mailto:rt4-whois-bounces@icann.org</a>] On<br>
Behalf Of Smith, Bill<br>
Sent: Tuesday, November 22, 2011 5:31 AM<br>
To: <a href="mailto:denise.michel@icann.org">denise.michel@icann.org</a><br>
Cc: <a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><br>
Subject: Re: [Rt4-whois] Adopting Specification 4 of the AGB<br>
<br>
Denise,<br>
<br>
Thanks for the information on the various agreements and how ICANN, the<br>
.org, recommends changes to those agreements. I think these processes are<br>
useful and consistent with the multi-stakeholder model, but I have yet to<br>
see anything in the Bylaws or any policy document that requires contract<br>
changes through a PDP or any other "community process".<br>
<br>
Perhaps I am making to fine a point of this, but I consider it an important<br>
one, and that is that only the Board has the authority to enter into<br>
contracts. It may delegate that authority, typically for the purposes of<br>
negotiation and expedited execution. Further, in the case of ICANN, the<br>
corporation, it has a responsibility to enter into contracts that are in the<br>
public interest (writ large).<br>
<br>
Bill<br>
<br>
On Nov 21, 2011, at 11:18 AM, Denise Michel wrote:<br>
<br>
James - I'd be happy to contribute to this discussion.<br>
<br>
All -<br>
<br>
There are multiple ways to change the Registrar Accreditation Agreement<br>
(RAA) and the various Registry agreements (see current list at<br>
<<a href="http://www.icann.org/en/registries/agreements.htm>">http://www.icann.org/en/registries/agreements.htm></a>;).<br>
<br>
The RAA can be changed through the GNSO's policy development process (PDP)<br>
and through contract-based options. (See attached Policy Staff paper I sent<br>
a few weeks ago that details these processes; different issues and processes<br>
yield different results -- e.g. immediate mandatory change, change upon<br>
contract renewal, etc.). RAA changes are posted for public comment and<br>
approved by the Board.<br>
<br>
The existing gTLD Registries are governed by the individual Registry or<br>
Sponsorship Agreements (linked above). Staff works with the individual gTLD<br>
Registry to review and change the provisions of their Registry or<br>
Sponsorship Agreement. Changes are posted for public comment and ultimately<br>
approved by the Board. There also is precedent for a PDP aimed at changes<br>
to existing registry contracts (see<br>
<<a href="http://gnso.icann.org/issues/gtld-policies/>">http://gnso.icann.org/issues/gtld-policies/></a>;), but this is the exception.<br>
In addition, a Registry may file an RSEP application to add a new service<br>
(and change its contract) (information on this is posted at<br>
<<a href="http://www.icann.org/en/registries/rsep/>">http://www.icann.org/en/registries/rsep/></a>;). Finally, as you've discussed,<br>
the Applicant Guidebook contains obligations that will be incorporated in<br>
new gTLD registry agreements.<br>
<br>
Please let me know if you need more information.<br>
<br>
Regards,<br>
Denise<br>
<br>
On Thursday, November 17, 2011, James M. Bladel<br>
<<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>><mailto:<a href="http://jbladel@godaddy.com">jbladel@godaddy.com</a>>> wrote:<br>
> I don't think I'm covering this topic adequately. Denise, perhaps you<br>
could weigh in on Bill's questions?<br>
><br>
> J.<br>
><br>
> -------- Original Message --------<br>
> Subject: Re: [Rt4-whois] Adopting Specification 4 of the AGB<br>
> From: "Smith, Bill"<br>
<<a href="http://bill.smith@paypal-inc.com">bill.smith@paypal-inc.com</a>><mailto:<a href="http://bill.smith@paypal-inc.com">bill.smith@paypal-inc.com</a>>><br>
> Date: Thu, November 17, 2011 2:56 pm<br>
> To: "James M. Bladel" <<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>><mailto:<a href="http://jbladel@godaddy.com">jbladel@godaddy.com</a>>><br>
> Cc: Susan Kawaguchi <<a href="mailto:susank@fb.com">susank@fb.com</a>><mailto:<a href="http://susank@fb.com">susank@fb.com</a>>>,<br>
"<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>>"<br>
> <<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>>><br>
><br>
> James,<br>
><br>
> Thanks for the quick reply.<br>
><br>
> Sorry to be slow, but I still don't see where "contract modification"<br>
requires a PDP (and Issues Report, etc.). The section you referenced<br>
describes how new specifications and policies are developed, not how<br>
contracts are amended.<br>
><br>
> As best I can tell, it's up to the ICANN Board to make the determination<br>
on contract language.<br>
><br>
> Bill<br>
><br>
> On Nov 17, 2011, at 12:42 PM, James M. Bladel wrote:<br>
><br>
> Bill:<br>
><br>
> This is described in Section 4 of the RAA. Here's a quick link:<br>
<a href="http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm#4">http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm#4</a><br>
><br>
><br>
> J.<br>
><br>
> -------- Original Message --------<br>
> Subject: Re: [Rt4-whois] Adopting Specification 4 of the AGB<br>
> From: "Smith, Bill"<br>
<<a href="http://bill.smith@paypal-inc.com">bill.smith@paypal-inc.com</a>><mailto:<a href="http://bill.smith@paypal-inc.com">bill.smith@paypal-inc.com</a>>><<a href="http://bill.sm">http://bill.sm</a><br>
<a href="mailto:ith@paypal-inc.com">ith@paypal-inc.com</a>/>&gt;<br>
> Date: Thu, November 17, 2011 2:38 pm<br>
> To: "James M. Bladel"<br>
<<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>><mailto:<a href="http://jbladel@godaddy.com">jbladel@godaddy.com</a>>><mailto:<a href="http://jbladel@godaddy.com">jbladel@godaddy.com</a><br>
><<a href="mailto:jbladel@godaddy.com">mailto:jbladel@godaddy.com</a>>>><br>
> Cc: Susan Kawaguchi<br>
<<a href="mailto:susank@fb.com">susank@fb.com</a>><mailto:<a href="http://susank@fb.com">susank@fb.com</a>>><mailto:<a href="http://susank@fb.com">susank@fb.com</a>><mailto:susank@fb.<br>
com>>>,<br>
"<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><<br>
<a href="mailto:rt4-whois@icann.org">mailto:rt4-whois@icann.org</a>>>"<br>
><br>
<<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a><br>
><<a href="mailto:rt4-whois@icann.org">mailto:rt4-whois@icann.org</a>>>><br>
><br>
> James,<br>
><br>
> I agree on the need for consensus re our recommendations.<br>
><br>
> Could you point me to the language that says the only way to modify a<br>
Contracted Party contract is through the PDP. I haven't been able to locate<br>
that in the Bylaws or the GNSO PDP. I'm sure it's somewhere but I can't find<br>
the policy or process document that states this.<br>
><br>
> Bill<br>
><br>
> On Nov 17, 2011, at 10:46 AM, James M. Bladel wrote:<br>
><br>
> Hi folks:<br>
><br>
> Reading this thread (and reflecting on the work Susan and I are doing<br>
w.r.t. Proxy services), I am reminded of the limited nature of this Review<br>
Team in making its recommendations. Like my favorite game show "Jeopardy,"<br>
it's not enough to have the correct answer. The format of the response (in<br>
our case, recommendation) is equally important.<br>
><br>
> Bearing this in mind, I submit that recommendations should include the<br>
following elements:<br>
> (1) Target (To whom are we directing the recommendation?)<br>
> (2) Mechanism (By what means will the recommended action be implemented?)<br>
> (3) Timeframe (What is the deadline for action? Note that in ICANN as well<br>
as the general world, if something is left open-ended, it will never be<br>
completed.)<br>
> (4) Communication, Measurement & Follow-up (Was implementation complete?<br>
Did it work? What can the next WHOIS RT take away from it?)<br>
><br>
> Note that if we are describing actions that would create new obligations<br>
for Contracted Parties (Registries & Registrars), we must reference the GNSO<br>
Policy Development Process (PDP, Annex A in the ICANN Bylaws) as part of our<br>
recommendation, the first step of which is requesting an Issues Report. This<br>
is the only way to create new obligations for contracted parties.<br>
><br>
> So, instead of:<br>
> "Registrars should fix Problem X."<br>
><br>
> A proper recommendation might look like:<br>
> "No later than Jul 2012, the ICANN Board should request a PDP Issues<br>
Report to examine the potential actions Registrars can take to address<br>
Problem X."<br>
><br>
> Also want to re-iterate that divided recommendations will most likely die<br>
on the table when presented to the Board. To ensure that each and every<br>
recommendation becomes reality, we must be unanimous in our presentation. If<br>
we aren't there yet with some of our recs, then we have to walk them back<br>
together until we can find middle ground (similar to what Susan and I are<br>
doing w.r.t. Proxy).<br>
><br>
> Thanks--<br>
><br>
> J.<br>
><br>
> Subject: Re: [Rt4-whois] FW: Adopting Specification 4 of the AGB<br>
> From: Susan Kawaguchi<br>
<<a href="mailto:susank@fb.com">susank@fb.com</a>><mailto:<a href="http://susank@fb.com">susank@fb.com</a>>><mailto:<a href="http://susank@fb.com">susank@fb.com</a>><mailto:susank@fb.<br>
com>>><<a href="mailto:susank@fb.com">mailto:susank@fb.com</a>><mailto:<a href="http://susank@fb.com">susank@fb.com</a>>><<a href="http://susank@fb.com/>>&g">http://susank@fb.com/>>&g</a><br>
t;<br>
> Date: Thu, November 17, 2011 12:00 pm<br>
> To: Kathy Kleiman<br>
<<a href="mailto:kathy@kathykleiman.com">kathy@kathykleiman.com</a>><mailto:<a href="http://kathy@kathykleiman.com">kathy@kathykleiman.com</a>>><mailto:kathy@kathykl<br>
<a href="http://eiman.com">eiman.com</a>><mailto:<a href="http://kathy@kathykleiman.com">kathy@kathykleiman.com</a>>>><mailto:<a href="http://kathy@kathykleiman.com">kathy@kathykleiman.com</a>><mai<br>
lto:<a href="mailto:kathy@kathykleiman.com">kathy@kathykleiman.com</a>>><<a href="http://kathy@kathykleiman.com/>>&gt">http://kathy@kathykleiman.com/>>&gt</a>;,<br>
><br>
"<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><<br>
<a href="mailto:rt4-whois@icann.org">mailto:rt4-whois@icann.org</a>>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:rt4-whois@ica<br>
<a href="http://nn.org">nn.org</a>>><<a href="http://rt4-whois@icann.org/>&gt">http://rt4-whois@icann.org/>&gt</a>;"<br>
<<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a><br>
><<a href="mailto:rt4-whois@icann.org">mailto:rt4-whois@icann.org</a>>>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:rt4-whois@i<br>
<a href="http://cann.org">cann.org</a>>><<a href="http://rt4-whois@icann.org/>>&gt">http://rt4-whois@icann.org/>>&gt</a>;<br>
><br>
> Hi Kathy,<br>
><br>
> Please see my comments below.<br>
> From: Kathy Kleiman<br>
[<a href="mailto:kathy@kathykleiman.com">mailto:kathy@kathykleiman.com</a><mailto:<a href="http://kathy@kathykleiman.com">kathy@kathykleiman.com</a>>]<br>
> Sent: Thursday, November 17, 2011 6:56 AM<br>
> To:<br>
<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><m<br>
ailto:<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a>>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:rt4-whois@ican<br>
<a href="http://n.org">n.org</a>>><<a href="http://rt4-whois@icann.org/>&gt">http://rt4-whois@icann.org/>&gt</a>;; Susan Kawaguchi<br>
> Subject: Re: [Rt4-whois] FW: Adopting Specification 4 of the AGB<br>
><br>
> Dear Susan,<br>
> I understand your desire to see a Thick Whois Model imposed across the<br>
board. Watching the users on the video we watched in MDR struggle with the<br>
searches was painful. Knowing that you struggle with this issue every day is<br>
even worse.<br>
><br>
> However, adopting the Applicant Guidebook provisions for New Registries I<br>
don't see as being the right answer. In part, because it raises as many<br>
questions as it answers, and it may pose instability to the Net. If your<br>
assertion is true then we obviously have much bigger issues to deal with but<br>
I have followed the new gTld process from the very beginning, through all<br>
the versions and discussions of the AGB, had internal technical people<br>
evaluate the processes ICANN is advocating and have never heard a concern<br>
that Specification 4 would cause instability to the internet.<br>
><br>
> To expand: As we have discussed, in the early days, the functions of<br>
Registry and Registrar were not separate and Network Solutions both managed<br>
the database for .COM, .ORG and NET, and also registered domain names into<br>
it.<br>
><br>
> In 1999, I believe, ICANN introduced the first bit of competition, 4<br>
registrars to register domain names into the new gTLDs. As more competition<br>
in the registrar business came in (considered a hallmark of ICANN's work to<br>
introduce competition into the domain name space), the registrars began<br>
banging on Network Solutions, then owned by SAIC, then purchased by<br>
Verisign, to stop their compete ownership and control of the Whois<br>
information. It was an element of the competitive nature of the new domain<br>
name space to break up the information so one registry would not own and<br>
control it all. Completely understand the history but the need to create<br>
competition within the registrar space is no longer an issue. What we are<br>
facing now is a real need for the internet consumer to be able to easily<br>
look up a domain name registration. Whether that is converting the .com and<br>
.net registries to a Thick Whois model or ICANN creating a centralized WHOIS<br>
data base by collecting all the WHOIS !<br>
information from each registrar I could advocate for either option. (I<br>
think Lutz is drafting a proposal for this option) If the team does not<br>
address this issue, in my mind, we have not done our job. It is crucial that<br>
the information for a domain name is available and accurate (privacy and<br>
proxy registrations aside as that is still viable WHOIS information).<br>
><br>
> The key concern was, of course, .COM. And these issues, and the real<br>
concern of this largest of the registry database, now numbering almost 100<br>
million names (Oct 2011), would control the customer data and be able to<br>
bypass the new registrars and compete directly for the registration<br>
business, as well as creating a series of additional business functions.<br>
It's an enormous set of competitive data (as we heard from the Registrars in<br>
the Registry/Registrar meeting in Singapore with us) Registrars remain very<br>
committed to this model, and for legitimate reasons. This is a redherring.<br>
There are many ways that they all collect competitive data and having one<br>
source that is accurate, available and searchable would benefit the internet<br>
consumers in general and not the smaller segment of just registrars or<br>
registries .<br>
><br>
> Further, the danger of converting a 100 million database is enormous. When<br>
the Public Interest Registry took over the .ORG contract (after competitive<br>
applications), among the first things it had to do was convert the ORG<br>
registrations to thick ones. There were only a few million registrations at<br>
the time and it was still an enormous and delicate task. It was a huge<br>
moment. I understand for a small company transitioning databases can be<br>
harrowing but Verisign is a well funded, large organization and well<br>
equipped to scope out the process before hand and put all the necessary<br>
safeguards in place. Truly 100 million records is not that significant any<br>
more when you look at the large internet companies and how many users or<br>
accounts that are created every day.<br>
><br>
> Such a change, now to the enormous .COM database, is not an easy one to<br>
think about. Every major company in the world has a .COM registration. These<br>
websites are 24*7 operations. The risk to the Security & Stability of the<br>
Net would be one to study closely and carefully. The difficulties, not to<br>
mention risks and liabilities, would be enormous. The Thin Whois database<br>
could continue to exist to address any identified issues with security and<br>
stability of the internet. I am fine with the requirement to run both Thick<br>
and Thin. The ICANN centralized database proposal would essentially do that.<br>
><br>
> Is there something we can do, within the confines of our mandate and our<br>
fact-based research and assessment. Yes, I really think there are.<br>
><br>
> We have some key things we have agreed to:<br>
> 1) Findability - thin registration data should be findable. That's a<br>
technical issue (broken links) and an educational issue (what's a thin<br>
Whois, or better yet, how to I find .COM data). On education, there is much<br>
we can do to educate and help Law Enforcement and Fraud Investigators<br>
(public and private) to find the data we need. Let's include some<br>
recommendations on these. I have never had an issue (to date) with finding<br>
Thin registration data. Verisign data is always available and probably<br>
always accurate. But it is not enough data. We need the THICK WHOIS data to<br>
protect the internet consumer.<br>
> 2) Access & Accuracy - as we have already been discussing and which are<br>
key.<br>
><br>
> One thing we could do (and it will make us few friends) is to throw this<br>
kettle of fish into the hands of the registries and registrars on a<br>
timeframe, e.g., six months or one year, for their solutions and<br>
recommendations. They, together with the Community which must review and<br>
accept their solutions, must move quickly. Without specific recommendations<br>
and ( I agree with you) a specific time frame I do not have any faith in<br>
solving this issue.<br>
> I do agree that we should not get to deep into the details but if we do<br>
not provide clear findings and actionable recommendations I fear we will be<br>
arguing about this for the next decade.<br>
><br>
><br>
> But I don't think we can mandate a specific answer.<br>
> Best,<br>
> Kathy<br>
><br>
><br>
><br>
><br>
><br>
> :<br>
> Just realized that I did not attach the document to this email last week.<br>
><br>
> From: Susan Kawaguchi<br>
> Sent: Tuesday, November 08, 2011 11:13 PM<br>
> To:<br>
<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><m<br>
ailto:<a href="mailto:rt4-whois@icann.org">rt4-whois@icann.org</a>>><mailto:<a href="http://rt4-whois@icann.org">rt4-whois@icann.org</a>><mailto:rt4-whois@ican<br>
<a href="http://n.org">n.org</a>>><<a href="http://rt4-whois@icann.org/>&gt">http://rt4-whois@icann.org/>&gt</a>;<br>
> Subject: Adopting Specification 4 of the AGB<br>
><br>
> Attached is a draft of recommendations for adopting Specification 4 of the<br>
AGB for existing gTlds.<br>
><br>
> At the end of the document are rough thoughts on ICANN creating a<br>
voluntary program for registrars to be considered A list registrars. This<br>
would recognize the responsible registars and the proactive service they<br>
provide.<br>
><br>
> I will not be on the call tonight since it is 3 am my time. Not sure<br>
anything I would say would make any sense.<br>
><br>
> Susan Kawaguchi<br>
> Domain Name Manager<br>
><br>
> Facebook Inc.<br>
> 1601 California Avenue<br>
> Palo Alto, CA<br>
><br>
> Phone - 650 485-6064<tel:650%20485-6064><br>
> Cell - 650 387 3904<tel:650%20387%203904><br>
><br>
> Please note my email address has changed to<br>
<a href="mailto:skawaguchi@fb.com">skawaguchi@fb.com</a><mailto:<a href="http://skawaguchi@fb.com">skawaguchi@fb.com</a>><mailto:<a href="http://skawaguchi@fb.com">skawaguchi@fb.com</a>><mailto:<br>
<a href="mailto:skawaguchi@fb.com">skawaguchi@fb.com</a>>><mailto:<a href="http://skawaguchi@fb.com">skawaguchi@fb.com</a>><mailto:<a href="http://skawaguchi@fb.com">skawaguchi@fb.com</a>>><http<br>
:<a href="mailto://skawaguchi@fb.com">//skawaguchi@fb.com</a>/>&gt;<br>
> NOTICE: This email (including any attachments) may contain information<br>
that is private, confidential, or protected by attorney-client or other<br>
privilege. Unless you are the intended recipient, you may not use, copy, or<br>
retransmit the email or its contents.<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
><br>
> Rt4-whois mailing list<br>
><br>
><br>
<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><m<br>
ailto:<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a>>><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><mailto:Rt4-whois@ican<br>
<a href="http://n.org">n.org</a>>><<a href="http://Rt4-whois@icann.org/>&gt">http://Rt4-whois@icann.org/>&gt</a>;<br>
><br>
> <a href="https://mm.icann.org/mailman/listinfo/rt4-whois">https://mm.icann.org/mailman/listinfo/rt4-whois</a><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
><br>
><br>
><br>
><br>
> ________________________________<br>
> _______________________________________________<br>
> Rt4-whois mailing list<br>
><br>
<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><m<br>
ailto:<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a>>><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><mailto:Rt4-whois@ican<br>
<a href="http://n.org">n.org</a>>><<a href="http://Rt4-whois@icann.org/>&gt">http://Rt4-whois@icann.org/>&gt</a>;<br>
> <a href="https://mm.icann.org/mailman/listinfo/rt4-whois">https://mm.icann.org/mailman/listinfo/rt4-whois</a><br>
> _______________________________________________<br>
> Rt4-whois mailing list<br>
><br>
<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><m<br>
ailto:<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a>>><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><mailto:Rt4-whois@ican<br>
<a href="http://n.org">n.org</a>>><<a href="http://Rt4-whois@icann.org/>&gt">http://Rt4-whois@icann.org/>&gt</a>;<br>
> <a href="https://mm.icann.org/mailman/listinfo/rt4-whois">https://mm.icann.org/mailman/listinfo/rt4-whois</a><br>
><br>
><br>
><br>
<Final RAA Discussion Paper 13-10-11v3<br>
(1).pdf>_______________________________________________<br>
Rt4-whois mailing list<br>
<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a><mailto:<a href="http://Rt4-whois@icann.org">Rt4-whois@icann.org</a>><br>
<a href="https://mm.icann.org/mailman/listinfo/rt4-whois">https://mm.icann.org/mailman/listinfo/rt4-whois</a><br>
<br>
<br>
_______________________________________________<br>
Rt4-whois mailing list<br>
<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/rt4-whois">https://mm.icann.org/mailman/listinfo/rt4-whois</a><br>
<br>
_______________________________________________<br>
Rt4-whois mailing list<br>
<a href="mailto:Rt4-whois@icann.org">Rt4-whois@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/rt4-whois">https://mm.icann.org/mailman/listinfo/rt4-whois</a><br>
</div>
</blockquote></span></body></html>