ICANN/GNSO GNSO Email List Archives

[council]


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

RE: [council] Agenda Request

  • To: <ross@xxxxxxxxxx>
  • Subject: RE: [council] Agenda Request
  • From: <Lucy.Nichols@xxxxxxxxx>
  • Date: Tue, 14 Mar 2006 13:03:49 -0600
  • Cc: <council@xxxxxxxxxxxxxx>
  • In-reply-to: <44170AE8.4050403@tucows.com>
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcZHlVAfLDItZP5OQXqk6pXjdwi4twAA7RMQ
  • Thread-topic: [council] Agenda Request

May I raise another issue with respect to either today's agenda or at
least for the council to consider prior to Wellington---that of
addressing the WIPO-II issues --which have been incorporated into the
PDP-Dec05 --by means of a committee or whatever other type body is
appropriate.  

The IPC constituency statement outlines one approach but I think it is
time to take some concrete actions in getting this issue resolved.

This would also allow ICANN to finally respond to WIPO advising them
that the matter is being addressed. 

Your comments are welcomed.

Lucy

>-----Original Message-----
>From: owner-council@xxxxxxxxxxxxxx
[mailto:owner-council@xxxxxxxxxxxxxx] On
>Behalf Of ext Ross Rader
>Sent: Tuesday, March 14, 2006 12:27 PM
>Cc: council@xxxxxxxxxxxxxx
>Subject: Re: [council] Agenda Request
>
>Marilyn Cade wrote:
>> It is interesting to consider how best to proceed. Ross, do you have
an outline
>> in mind that we can sort of bat back and forth among intersted
councilors in a
>> discussion over the next week or two? So that we could actually then
formulate
>> what a request for an issues report might look like? Also, there is
perhaps
>> another step taht can be taken and that is the development of a
background paper
>> -- similar to what Maria did on the second level names, although in
this case,
>> it might be that the background would largely be provided by
operations staff?
>> Have to think more about that, overall.
>
>Thanks for the suggestion. Here is a possible way forward. We already
>have a practice that has support amongst registrars and registries i.e.
>the existing RGP (RGP 1.0?) is already support by a number of
registries
>and registrars. The problem is, RGP 1.0 is not consensus policy, it is
a
>registry service. This means that not all registrants have access to
RGP
>1.0 in the event that they lose their name because they failed to pay a
>renewal fee. I don't believe that anyone thinks that registrant's
should
>lose their domain name if they fail to pay a renewal fee, which is why
>we designed RGP 1.0 in the first place. The problem is, because the
>implementation of RGP 1.0 was brought forth as a registry service and
>not consensus policy, no registrar or registry is required to implement
>it. Some have suggested that this is a fair point of competitive
>differentiation. My view is that this isn't the case, and that all
>registrants should have access to this otherwise fair program. Ensuring
>that registrants have access to the RGP would be a matter for consensus
>policy development.
>
>My recommendation would be to proceed with a very narrow terms of
>reference to ensure that we can close the question fairly quickly, but
>also to leave room for future policy development.
>
>i.e. The goal of this PDP will be to evaluate whether or not the
>existing RGP should be implemented as consensus policy. In the event
>that there is a recommendation to implement the existing RGP as
>consensus policy, an analysis of the effectiveness of the adopted
>consensus policy should be undertaken within 6 months of its
implementation.
>
>I don't think opening the RGP up for amendment at this point would be
>entirely useful - changes to the policy might be required at some point
>in the future to ensure maximum effectiveness, but I think it would be
>prudent to address implementation and improvement as separate tasks.
>(i.e. we can get 90% of the way there over the short term, and then try
>to get traction on improvements over the longer term.)
>
>Is this what you were thinking? Happy to clarify further.
>
>Thanks again,
>
>-ross




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