[gnso-vi-feb10] RE: Proposed Addendum to Proposals
- To: Jeff Eckhaus <eckhaus@xxxxxxxxxxxxxxx>, "'Gnso-vi-feb10@xxxxxxxxx'" <Gnso-vi-feb10@xxxxxxxxx>
- Subject: [gnso-vi-feb10] RE: Proposed Addendum to Proposals
- From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
- Date: Mon, 14 Jun 2010 17:31:08 -0400
Thanks Jeff. I think this is a useful contribution.
I have enclosed some language that Neustar had in its original proposal (called
the Neustar proposal), which was subsumed into the JN2 proposal. Although JN2
does not go into detail, it does reference audits in 7(ii) and 8(ii) and these
could be the requirements. The original Neustar proposal (which is no longer
fully on the table), can be found at:
http://forum.icann.org/lists/gnso-vi-feb10/msg00720.html. I have excerpted the
relevant language on protections, audits, etc.. just as an illustration. THIS
IS NOT A NEW PROPOSAL.
b) In addition, in the event that RSP or any of its Affiliates
is a Registrar for the TLD, the following restrictions shall apply:
1. Affiliated Registrar may not receive directly or indirectly
preferential pricing from Registry Operator (i.e., direct pricing, rebates,
discounts, marketing contracts, etc.).
2. RSP must have strict controls on use of data for any purpose other than
acting as the RSP and must have information "firewall" between data in the
registry and its Registrar Affiliate.
3. No confidential information of the Registry Operator obtained by the
RSP may be shared with registrar Affiliate of RSP except as necessary to
perform the Registry Services and only for such purpose.
4. RSP shall not provide any access to any Registry Data to its Registrar
Affiliate, and RSP itself will not use, confidential user data or proprietary
information of an-ICANN-accredited registrar served by Registry Operator,
received by RSP in the course of providing Registry Services, except as
necessary for registry management and operations.
5. In the case where an RSP has a Registrar Affiliate providing Registrar
services in the TLD, such RSP will conduct internal neutrality reviews on a
regular basis. In addition, it will agree to cooperate with an independent
third party ("Auditor") performing Annual Independent Neutrality Audits ("AIN
Audits"), to be conducted each calendar year. All costs of the AIN Audits will
be borne by RSP. The AIN Audit is intended to determine whether Back-end
Operator has been in compliance, and will utilize such tests and techniques as
the auditor deems appropriate to determine that compliance.
6. Strict Penalties/Sanctions will be applied to any entity violating
these policies. Sanction Program can use old Appendix Y of .com agreement as
Jeffrey J. Neuman
Neustar, Inc. / Vice President, Law & Policy
The information contained in this e-mail message is intended only for the use
of the recipient(s) named above and may contain confidential and/or privileged
information. If you are not the intended recipient you have received this
e-mail message in error and any review, dissemination, distribution, or copying
of this message is strictly prohibited. If you have received this communication
in error, please notify us immediately and delete the original message.
From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On
Behalf Of Jeff Eckhaus
Sent: Monday, June 14, 2010 4:55 PM
Subject: [gnso-vi-feb10] Proposed Addendum to Proposals
After today's discussions with this group and reading the emails on the list, I
have noticed a consistent concern coming from many group members, that they are
worried about ICANN's ability to enforce any rules that are put in place. It is
one of the main concerns opponents of the JN2 proposal have expressed with the
issue of co-ownership. Specifically being able to police the following issue:
"Registry Operator or its Affiliate may serve as an ICANN-Accredited Registrar
in any top-level domain other than the TLD for which Registry Operator or its
Affiliate serves as the Registry Operator" .
Those opposed to JN2 and other proposals seem to agree that cross-ownership is
appropriate, but that ICANN will not be able to police any restrictions on data
sharing between a registry and registrar. They believe that we cannot simply
rely on Registrars to adhere to a signed agreement. Thus, because compliance
will be too difficult to enforce, we must limit cross-ownership.
While I disagree with this viewpoint, my opinion does not matter at this point.
What does matter is assuring the people who are concerned with the above,
attempting to bridge the gap and reach consensus. To that end, I am proposing
an unsolicited addendum to the JN2 proposal (maybe JN3 now??) and to any other
proposals that allow a Registry to own up to 100% of a Registrar (vice-versa)
but not distribute the owned TLD.
This will only apply to co-owned entities that have an ownership level above
the 2% threshold as discussed in the DAGv4:
* The Registry/Registrar must agree to an annual audit for the first 2
years. Every 18 months for next 3 years, and every 2 years thereafter. (timing
can be negotiated)
* The audit will focus on ensuring that Registry data is not shared
with the co-owned Registrar, co-owned Resellers, and any related Affiliates
o Details of what data would need to be audited would be supplied by a
working group/committee led by current Registries
* Stiff penalties would be levied if there is an audit failure (amounts
* All costs of the audit would be borne by the co-owned entity
o The co-owned entity would pay fees into a pool, not directly to auditors.
This avoids any thoughts of impropriety
* This audit would be in addition to the audit and compliance
requirements already agreed to in ICANN Registry and Registrar agreements
* Auditors would be independent of ICANN but would work with ICANN
Compliance on fees and remedies
* Auditors would be rotated among assignments to avoid capture
This is the framework of my proposal that I believe would cover Registrant
rights and concerns and bring comfort to those who believe there will be
enhanced harms if there is any type of co-ownership. Most important it would
cover the policing/enforcement issues that seems to be the roadblock to
consensus. I welcome feedback on this idea and look forward to hearing more and
seeing everyone in Brussels.