[Rt4-whois] Adopting Specification 4 of the AGB

Tue Nov 22 16:50:37 UTC 2011

I am wondering if the distinction being made and perhaps missed here is that
changes to the RAA can be made mid-stream through the PDP but otherwise, a
change can only be implemented when the term of a given RAA runs out and is
up for renewal.  In other words, ICANN cannot force an amendment on a
registrar until that registrar's RAA is up for renewal, but a registrar's
obligations under the contract can be amended through a PDP because the
current RAA states that it may.

-----Original Message-----
From: rt4-whois-bounces at icann.org [mailto:rt4-whois-bounces at icann.org] On
Behalf Of Smith, Bill
Sent: Tuesday, November 22, 2011 5:31 AM
To: denise.michel at icann.org
Cc: rt4-whois at icann.org
Subject: Re: [Rt4-whois] Adopting Specification 4 of the AGB

Denise,

Thanks for the information on the various agreements and how ICANN, the
.org, recommends changes to those agreements. I think these processes are
useful and consistent with the multi-stakeholder model, but I have yet to
see anything in the Bylaws or any policy document that requires contract
changes through a PDP or any other "community process".

Perhaps I am making to fine a point of this, but I consider it an important
one, and that is that only the Board has the authority to enter into
contracts. It may delegate that authority, typically for the purposes of
negotiation and expedited execution. Further, in the case of ICANN, the
corporation, it has a responsibility to enter into contracts that are in the
public interest (writ large).

Bill

On Nov 21, 2011, at 11:18 AM, Denise Michel wrote:

James - I'd be happy to contribute to this discussion.

All -

There are multiple ways to change the Registrar Accreditation Agreement
(RAA) and the various Registry agreements (see current list at
<http://www.icann.org/en/registries/agreements.htm>).

The RAA can be changed through the GNSO's policy development process (PDP)
and through contract-based options. (See attached Policy Staff paper I sent
a few weeks ago that details these processes; different issues and processes
yield different results -- e.g. immediate mandatory change, change upon
contract renewal, etc.).  RAA changes are posted for public comment and
approved by the Board.

The existing gTLD Registries are governed by the individual Registry or
Sponsorship Agreements (linked above).  Staff works with the individual gTLD
Registry to review and change the provisions of their Registry or
Sponsorship Agreement. Changes are posted for public comment and ultimately
approved by the Board.  There also is precedent for a PDP aimed at changes
to existing registry contracts (see
<http://gnso.icann.org/issues/gtld-policies/>), but this is the exception.
In addition, a Registry may file an RSEP application to add a new service
(and change its contract) (information on this is posted at
<http://www.icann.org/en/registries/rsep/>).  Finally, as you've discussed,
the Applicant Guidebook contains obligations that will be incorporated in
new gTLD registry agreements.

Please let me know if you need more information.

Regards,
Denise

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

_______________________________________________
Rt4-whois mailing list
Rt4-whois at icann.org
https://mm.icann.org/mailman/listinfo/rt4-whois