ICANN ICANN Email List Archives

[gnso-pro-wg]


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

RE: [gnso-pro-wg] Current Proposals Chart

  • To: "Avri Doria" <avri@xxxxxxx>, "PRO WG" <gnso-pro-wg@xxxxxxxxx>
  • Subject: RE: [gnso-pro-wg] Current Proposals Chart
  • From: "Rosette, Kristina" <krosette@xxxxxxx>
  • Date: Thu, 17 May 2007 10:58:36 -0400

Would you please take a stab at drafting a definition of RPM that would
encompass them?   There is widespread sentiment among the IP community
that these requirements are an RPM.  As I've had no success with a
definition you can accept, it seems better to turn the drafting over to
you. 

-----Original Message-----
From: owner-gnso-pro-wg@xxxxxxxxx [mailto:owner-gnso-pro-wg@xxxxxxxxx]
On Behalf Of Avri Doria
Sent: Thursday, May 17, 2007 10:56 AM
To: PRO WG
Subject: Re: [gnso-pro-wg] Current Proposals Chart

Hi,

thanks for asking. as i indicated in the note i just sent, i think my
request for the alternative still stands since they are not RPMs but
alternatives which have a similar effect to RPMs

thanks

a.

On 17 maj 2007, at 16.14, Rosette, Kristina wrote:

> Avri,
>
> See my revised definition (just posted) of RPM.  Would you please let 
> me know if your comments below (that implicate RPM definition) still 
> stand?
>
> K
>
> -----Original Message-----
> From: owner-gnso-pro-wg@xxxxxxxxx [mailto:owner-gnso-pro-wg@xxxxxxxxx]
> On Behalf Of Avri Doria
> Sent: Thursday, May 17, 2007 5:56 AM
> To: PRO WG
> Subject: Re: [gnso-pro-wg] Current Proposals Chart
>
> Hi,
>
> I am assuming the chart is still the latest, as the draft you sent did
> not include the agreements or supported contents.
>
> I apologize that my difficulties with my phone connection made it hard
> for me to get these said during the meeting on Monday, though I did
> mention some of them.  I also needed some time to read and think about
> them based on our definitions.
>
> I have the following comments/edits:
>
> ------------------------------------------------------
> Re  1:
>
> I would like an alternative listed for 1.
>
> --
> New gTLDS MAY define a RPM.  This should not be a MUST as it is  
> possible
> that there may be new gTLDs defined for specific communities that are
> strict enough in their membership qualifications that such a mechanism
> would not be required.  there may also be other reasons for obviating
> the requirement for a RPM.
> --
>
> As I mentioned in the discussion I thought that in some cases, for
> example a TLD meant for a well defined community might not need such a
> mechanism. Someone, perhaps you, mentioned that such a strict  
> community
> night be count as a RPM, but in the definition of RPM, we do not  
> include
> that possibility.  I can also can imagine that there would be other
> cases where an RPM would be superfluous.
>
> ------------------------------------------------------
> re 2:
>
> I would like an alternative listed for 2.
>
> --
> Each gTLD applicant MUST describe in their application the methods  
> they
> will employ to protect the rights of others.
> --
>
> My reasons for this are similar to my reasons for #1. Not only is  
> there
> not a RPM that fits all cases, based on the definition of RPM, there
> should not be a RPM requirement that all gTLDS.  In some case the UDRP
> and Registration Agreement plus the community definition may be
> sufficient.  They should, however, identify how the rights of others,
> including those who do not hold Marks.  It occurs to me that we have
> never defined a central term to all of our discussions:
> Rights of others.  I would take a crack at it, but I expect my
> definition would not be the majority definition.  I will probably
> comment more on this as I review the definitions we tentatively  
> settled
> on last night.
>
> ------------------------------------------------------
> re 4;
>
> In general i am fine with this, but i think it is confusing.  Since I
> see no way for the definition of RPM to include " eligibility or
> membership verification requirements and second-level name selection
> criteria (such as those used by the .museum, .aero, and .travel
> TLDs)" I think it inappropriate to refer to this as a RPM.   I also
> beleive that there may be other, as of yet undefined conditions, that
> may make an RPM unnecessary - we cannot preclude the creativity and
> innovation in defining a TLD that might make an RPM unnecessary.  I
> would prefer it read:
>
> --
>
> If a new gTLD elects to adopt a description that includes  
> eligibility or
> membership verification requirements and second-level name selection
> criteria (such as those used by the .museum, .aero, and .travel  
> TLDs) or
> another similar set or criteria, a RPM SHALL NOT be necessary.
>
> --
>
> If this is not supportable by other, I would ask that it be listed  
> as an
> alternative.
>
> ------------------------------------------------------
> re 5,7:
>
> If 6 is moved to auxiliary concerns due to the reason, which I accept,
> of not dictating policy concerning fees, then I think the fee  
> portion of
> 5 and 7 in its entirety should also be move to the 'auxiliary  
> concerns'
> section
>
> Also the first sentence of 5 should be included, however, I  
> recommend it
> read:
>
> --
> There MUST be a challenge procedure for any RPM procedure.
> --
>
> since Legal rights cannot be verified, they must be challengeable.
> If this is not supportable by others, please include it as an  
> alternate.
>
> ------------------------------------------------------
> re 8,
>
> I have no argument against removing this, however, i feel that if  
> Legal
> Rights can only be asserted and not verified a-priori then I see it as
> difficult to justify taking definitive and blocking action on those
> right's assertions without using the existing mechanisms or the  
> courts.
>
> thanks
> a.
>
>
> On 16 maj 2007, at 23.20, Rosette, Kristina wrote:
>
>> All,
>>
>> Attached is a chart that contains all of the principles proposed to
>> date.  (Please check to make sure any you posted were included.) To
>> the extent we have previously discussed them and agreed upon a level
>> of support that is noted.  I added numbers for the sole purpose of
>> making it easier to refer to them on the list.  The numbers are not
>> intended to indicate any ranking.
>>
>> According to my notes, the following proposals have not been
>> discussed:  9, 16-17 (we discussed 18 & 19 during our call), 20-28.
>> Also according to my notes, Tim and Victoria planned to draft and
>> circulate new versions of 20-25.
>>
>> If you wish to comment, further discuss, propose revisions, please  
>> do.
>
>> It would be ideal if we could reach further consensus by
>> list.   Before I leave the office this evening, I will post a
>> current draft of the report for review and comment.
>>
>> Also, I will be unavailable from 5 PM (EDT) tomorrow through
>> Wednesday morning.   The report will be submitted by 5 PM EDT
>> tomorrow in whatever form it's in at that time.
>>
>> Kristina
>>
>>
>>
>> <<05162007 PRO WG Proposals Chart.DOC>>
>>
>> <05162007 PRO WG Proposals Chart.DOC>
>
>
>






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

Privacy Policy | Terms of Service | Cookies Policy