ICANN/GNSO GNSO Email List Archives

[council]


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

Re: [council] A few comments on RAA amendments

  • To: <icann@xxxxxxxxxxxxxx>, Kurt Pritz <kurt.pritz@xxxxxxxxx>, "'GNSO Council'" <council@xxxxxxxxxxxxxx>
  • Subject: Re: [council] A few comments on RAA amendments
  • From: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
  • Date: Fri, 30 Jan 2009 19:22:12 +0100
  • Cc: "'Mike Zupke'" <Mike.Zupke@xxxxxxxxx>
  • In-reply-to: <49ED48DEE5B4435A8793EBB2CA71DF08@HPLAPTOP>
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcmCP3x+2a25/OjZh0SRgK/fWIDQaAAAV7pgAABKCUAAMWn1SQ==
  • Thread-topic: [council] A few comments on RAA amendments
  • User-agent: Microsoft-Entourage/12.14.0.081024

Mike,

I really fail to understand your arguments and attempts to demonise
registrars on this.

Why is it crazy to have an incentive for registrars who opt to voluntarily
adopt a contract which will lead to more expense and the need to meet
tougher compliance requirements for them?

The proposed RAA changes would have meant registrars face new compliance
tools and increased enforcement efforts. Things which, while they certainly
seem to be called for by the community, can hardly be seen as a win-win
situation for registrars...

Thanks,

Stéphane Van Gelder


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

> 
> Thanks Kurt.  It is a crazy idea to incent registrars to accept changes that
> they have unilaterally negotiated with Staff.  Yet another win-win... for
> the registrars only.
> 
> Your suggestions appear to ignore the majority of the Council members that
> voted against the RAA package, generally on the basis that it should be
> revised with input from Council.  So why were we asked in the first place?
> 
> Why is it not an equally viable path as I have suggested?  Namely, let's
> form a group to agree which of the amendments have full consensus, which
> might quickly get full consensus, and which need work.  Those that need work
> can be set on a path to completion, and the others can be adopted by the
> Board, imposed on registrars upon renewal, and meanwhile adopted voluntarily
> by the reputable registrars.
> 
> In sum, I do not accept many of the assumptions of this note, and look
> forward to further discussion.
> 
> Thanks,
> Mike
> 
> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
> Behalf Of Kurt Pritz
> Sent: Thursday, January 29, 2009 10:29 AM
> To: GNSO Council
> Cc: Mike Zupke
> Subject: [council] A few comments on RAA amendments
> 
> 
> Council Members:
> 
> Some members of the GNSO Council have requested clarification about the
> procedures available to ICANN to implement an amended Registrar
> Accreditation Agreement (RAA) absent two-thirds approval by the GNSO. I
> thought it might be helpful to provide some writing on this even though we
> are just before the Council meeting. This can also be described during the
> meeting given that most will not have time to read and consider this before
> the meeting.
> 
> In the "GNSO Briefing Paper on Proposed RAA Amendments" provided to the GNSO
> Council on 29 October 2008 (see
> http://gnso.icann.org/mailing-lists/archives/council/msg05617.html), two
> possible adoption paths were described for amending RAA:
> 
>  
> 1. The RAA includes a provision for the adoption of changes that can be
> incorporated in a new contract that can be made mandatory for all registrars
> upon renewal. Specifically, RAA Subsection 5.4 details the process for RAA
> renewal and substitution of revised forms of the RAA, and sets forth a path
> that includes undertaking a consensus process as set forth in RAA Subsection
> 4.3. (The full text of RAA Subsections 5.4 and 4.3 are reprinted in Appendix
> I.) This process is similar in several respects to the current GNSO policy
> development process, encompassing community outreach and public comment, a
> written report and supporting materials documenting areas of agreement and
> disagreement and a recommendation adopted by at least a two-thirds vote of
> the Council. It is expected that such a consensus process would consider the
> set of proposed amendments as a whole. Consideration of changes to the set
> might require use of the formal GNSO PDP process.
>  
> 
>  
> 2. An alternative approach would leave the determination for approving the
> new form of RAA with the Board. However, since the consensus process
> described above would not be followed under this approach, the new form RAA
> might not be imposed mandatorily on registrars due to the RAA requirement.
> In order to gain acceptance under this approach, there might be incentives
> to encourage voluntary adoption of the new contract. One advantage to this
> approach would be that adoption could proceed without waiting for a renewal
> cycle to pass. There might be several potential incentives for registrars to
> adopt the new form of RAA immediately upon approval by the Board:
>  
> a. Recognition of those registrars agreeing to the new terms with a ³higher
> standards² status by ICANN and the community (a ³gold star² approach);
>  
> b. Fee incentives;
>  
> c. Heightened accreditation and renewal standards going forward;
>  
> d. Community and peer support for adopting the new form RAA.
>  
> 
> Because the GNSO did not approve the proposed amendments to the RAA with a
> two-thirds majority, the second approach described above now remains as the
> most viable path forward. Staff is currently evaluating this possibility.
> That is, the ALAC comments and recommendation and the results of the GNSO
> vote would be forwarded to the Board. The Board might consider the set of
> amendments for approval. This approval would not make the amendments
> mandatory in the RAA at any time and ICANN might offer incentive(s) for
> Registrars to adopt them. Again, this path is not certain.
> 
> I hope this is helpful. I am free to discuss this on email or on the phone.
> 
> Regards,
> 
> 
> Kurt
> 
> 
> 



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