ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] RAA Amendments

  • To: <icann@xxxxxxxxxxxxxx>, Kurt Pritz <kurt.pritz@xxxxxxxxx>, <council@xxxxxxxxxxxxxx>
  • Subject: Re: [council] RAA Amendments
  • From: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
  • Date: Thu, 19 Feb 2009 19:49:05 +0100
  • In-reply-to: <BEE76379E71046798F0C05361240E69E@HPLAPTOP>
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcmSAJtN8hesSGFwZUi2SUOH5G4+oQADZGrAAASZs2AAIgpQLAACDIRQAARzf4Q=
  • Thread-topic: [council] RAA Amendments
  • User-agent: Microsoft-Entourage/12.14.0.081024

Mike,

Thanks for clarifying. Under the ICANN Bylaws, the GNSO is a
policy-making body and not a body to be drafting contract language to be
sent to the Board in an attempt to bind a party to provisions without
their consent - especially provisions outside of those enumerated in
the contract as the potential subject matter of policies (the picket
fence).

This appears to be nothing more than a land grab, which is outside the
scope of the GNSO. If you want to bind registrars to a new policy on
something within the picket fence, go through the PDP process. You
appear to be trying to do an end run around the PDP process and the
picket fence, however, in violation of ICANN's Bylaws and contracts, and
your attempt should be unacceptable to the Council.

Stéphane


Le 19/02/09 17:47, « Mike Rodenbaugh » <icann@xxxxxxxxxxxxxx> a écrit :

> Stephane,
> 
> I agree we should get ICANN Counsel's interpretation as a logical next step
> in this debate.
> 
> The intent of my motion is to have Council agree on a subset of the
> amendments agreed between ICANN Staff and the Registrars Constituency, and
> forward that recommendation to the Board for compulsory implementation.
> Then, the Council would provide guidance as to additional and/or different
> amendments that the community would like to see made to the RAA, and forward
> that recommendation to the Board as well.
> 
> Thanks,
> Mike
> 
> -----Original Message-----
> From: Stéphane Van Gelder [mailto:stephane.vangelder@xxxxxxxxx]
> Sent: Thursday, February 19, 2009 7:43 AM
> To: icann@xxxxxxxxxxxxxx; Kurt Pritz; council@xxxxxxxxxxxxxx
> Subject: Re: [council] RAA Amendments
> 
> Mike,
> 
> We obviously disagree with your expansive interpretation of the RAA, and
> would welcome guidance from the General Counsel on this issue.
> 
> Per your motion, would you have the Council formulate and seek to approve
> amendments to the RAA that are not supported by both of the parties to the
> contract?  In other words, is the intent of your motion to provide guidance
> to the parties or to have Council move forward and approve changes that it
> thinks is best?
> 
> Thanks.
> 
> Stéphane Van Gelder
> 
> 
> Le 19/02/09 00:34, « Mike Rodenbaugh » <icann@xxxxxxxxxxxxxx> a écrit :
> 
>> 
>> Thanks Kurt.  You are interpreting the RAA in a very narrow and
>> unprecedented way, as Section 4.2 simply says "policies may be established
>> on the following topics..."  It does not preclude policy on any other
> topic.
>> Has ICANN Counsel created this interpretation, or is it simply yours?
>> 
>> Moreover, are these your personal opinions as to what falls within and
>> outside the 'picket fence' that you have now attempted to create?  Are
> they
>> ICANN Counsel's opinions?  Who is it ultimately that would make those
>> determinations (if we accepted for the moment that such determinations
> must
>> be made)?  Surely the GNSO Council's collective opinion on any such
>> determination ought to be at least as important as ICANN Staff's, and very
>> well might differ.
>> 
>> In particular, it appears illogical to say that the Council can develop
>> policy on substantive issues, but cannot develop policy to enforce the
>> resulting rules (via notifications to registrars, auditing,
>> sanctions/suspension, etc.).
>> 
>> Also I do not comprehend your attempted distinction between 'policy
> relating
>> to warehousing' and policy 'requiring registrars to comply with all RAA
> and
>> consensus policy requirements for names registered by the registrar'.
>> 
>> Regardless of these concerns, I hope the Council will approve the path
>> forward that I have suggested, so that we can reach consensus as to a
>> package of amendments that can be implemented on a compulsory basis as
> soon
>> as possible.  That motion is on the table for Mexico City, so hopefully
>> Staff will give us its views on that motion as soon as possible, as well
> as
>> further responses to my specific questions above.
>> 
>> Thanks,
>> Mike
>> 
>> 
>> -----Original Message-----
>> From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx]
> On
>> Behalf Of Kurt Pritz
>> Sent: Wednesday, February 18, 2009 11:39 AM
>> To: Council GNSO
>> Subject: [council] RAA Amendments
>> 
>> 
>> Dear All:
>> 
>> In follow up to my earlier comments and in response to some of the
>> subsequent discussion by the Council, I thought it might be helpful to
>> clarify the options available to ICANN in modifying registrar obligations
>> under the Registrar Accreditation Agreement (RAA).  My earlier comments
>> indicated that two paths were considered to incorporate amendments into
> the
>> RAA.
>>  
>> There are, of course, three ways by which registrar obligations under the
>> RAA can be modified:
>>  
>> The first option, which is described in the RAA, requires a report,
> approval
>> by a two-thirds majority of the GNSO, and ICANN Board action.  As
> indicated
>> previously, a new form of RAA adopted based on a two-thirds¹ vote of the
>> Council would take effect upon expiration of each registrar¹s five-year
> RAA.
>> With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31
>> May 2011, the result would have been substantial (compulsory) adoption of
>> the new RAA and significantly improved availability of compliance
>> enforcement tools for most registrars. The proposed amendments did not
>> receive the requisite two-thirds vote for approval.  Staff will continue
> to
>> engage the GNSO membership to address outstanding concerns raised in the
>> process, to determine whether RAA amendment through this path may still be
>> viable.
>>  
>> The second option for amending the RAA requires Board approval and the
>> voluntary adoption of a revised RAA by registrars.  It is anticipated that
>> some forms of incentive would be required to encourage adoption as I
>> previously described.
>>  
>> The third option is the GNSO policy development process that has the
> ability
>> to modify the terms under which ICANN-accredited registrars do business
>> through the policy development process.  In particular, the RAA (at
> section
>> 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2)
> allows
>> for the establishment and revision of policies and specifications in the
>> following areas:
>>  
>> 4.2.1 issues for which uniform or coordinated resolution is reasonably
>> necessary to facilitate interoperability, technical reliability, and/or
>> operational stability of Registrar Services, Registry Services, the DNS,
> or
>> the Internet;
>>  
>> 4.2.2 registrar policies reasonably necessary to implement ICANN policies
> or
>> specifications relating to a DNS registry or to Registry Services;
>>  
>> 4.2.3 resolution of disputes concerning the registration of Registered
> Names
>> (as opposed to the use of such domain names), including where the policies
>> take into account use of the domain names;
>>  
>> 4.2.4 principles for allocation of Registered Names (e.g.,
>> first-come/first-served, timely renewal, holding period after expiration);
>>  
>> 4.2.5 prohibitions on warehousing of or speculation in domain names by
>> registries or registrars;
>>  
>> 4.2.6 maintenance of and access to accurate and up-to-date contact
>> information regarding Registered Names and nameservers;
>>  
>> 4.2.7 reservation of Registered Names that may not be registered initially
>> or that may not be renewed due to reasons reasonably related to (a)
>> avoidance of confusion among or misleading of users, (b) intellectual
>> property, or (c) the technical management of the DNS or the Internet
> (e.g.,
>> "example.com" and names with single-letter/digit labels);
>>  
>> 4.2.8 procedures to avoid disruptions of registration due to suspension or
>> termination of operations by a registry operator or a registrar, including
>> allocation of responsibility among continuing registrars of the Registered
>> Names sponsored in a TLD by a registrar losing accreditation; and
>>  
>> 4.2.9 the transfer of registration data upon a change in registrar
>> sponsoring one or more Registered Names.
>>  
>> These topics mark the boundaries of the "picket fence" within which policy
>> development under the current RAA is possible.  (A two-thirds GNSO
> majority
>> would still be required in order for such policies to be enforceable
> against
>> registrars, as is the case with the RAA amendment process.)
>>  
>> The current set of proposed amendments, reached through community
>> consultation and negotiation with registrars, would reach several areas
> that
>> are not ordinarily subject to policy development within the picket fence.
>> Please keep in mind that we are not evaluating the specific amendments,
> just
>> the realm of potential policy development, and also that our analysis may
>> not have taken all factors into account.  In other words, the
> determination
>> of what's inside the picket fence could conceivably result in a different
>> answer under different circumstances.
>>  
>> The following topics that were included in the original package of
>> amendments sent to the GNSO do appear to fall within the picket fence of
>> potential new obligations that could be imposed on registrars via
> Consensus
>> Policies:
>>  
>> ·      Escrow of Whois Privacy/Proxy Customer Data
>>  
>> ·      Registrant Rights and Responsibilities Document
>>  
>> ·      Registrar Contractual Relationships with Resellers (where the
>> substantive topic lies within the picket fence)
>>  
>> ·      Disclosure of Registration Licensee Contact Information
>>  
>> ·      Registrar Disclosure of Its Own Contact Information
>>  
>> ·      Operator Skills Training & Testing
>>  
>> ·      Modification of Data Retention Requirements
>>  
>> Based on our initial review, the following topics that were included in
> the
>> original package of amendments sent to the GNSO appear to fall outside the
>> picket fence, and therefore could not be imposed on registrars via
> Consensus
>> Policies:
>>  
>> ·      Registrar Auditing
>>  
>> ·      Graduated Sanctions & Accreditation Suspension
>>  
>> ·      Registrar Group Liability
>>  
>> ·      Registrar Fees
>>  
>> ·      Registrations by Registrars (the picket fence allows for policy
>> development related to warehousing of domains by registrars, but the topic
>> addressed by the proposed amendment - requiring registrars to comply with
>> all RAA and consensus policy requirements for names registered by the
>> registrar for registrar business use - would not be enforceable as a
>> Consensus Policy under the RAA)
>>  
>> ·      Modification of Arbitration Rights
>>  
>> ·      Accreditation by Purchase
>>  
>> ·      Use of ICANN-Accredited Registrars (is a topic appropriate for
> policy
>> development by the GNSO, but it would not be enforceable through the RAA
> as
>> a "Consensus Policy")
>>  
>> ·      Streamlined Requirements for Registrar Notification of New and
>> Revised Consensus Policies
>>  
>> ·      Removal of References to U.S. Department of Commerce
>>  
>> It is our expectation that the GNSO will continue to evaluate the need for
>> and undertake policy development within the picket fence that would be
>> applicable to all registrars. Nevertheless, we still see strong value to
>> registrants and the greater Internet community in the proposed amendments,
>> even if they cannot be uniformly applied at this time.  In the event a
>> system of incentives is implemented to encourage voluntary adoption by
>> registrars, we will, of course, consult with the GNSO and its
>> member-constituencies as we have throughout this process, to solicit input
>> with regard to the most beneficial and meaningful ways and tools to
>> encourage registrar cooperation.
>> 
>> I hope this information is helpful and clear. I will answer what questions
> I
>> can and get answers to others.
>> 
>> Regards,
>> 
>> Kurt
>> 
>> Kurt Pritz
>> ICANN
>> 
>> 4676 Admiralty Way, Ste. 330
>> Marina del Rey, CA 90292
>> 
>> +1-310-301-5809 (office)
>> +1-310-400-4184 (mobile)
>> 
>> 
>> 
>> 
> 
> 






<<< Chronological Index >>>    <<< Thread Index >>>