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 11:29:12 -0400

Works for me. 

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

hi,

It would be presumptuous, and a bit foolish, of me to try and define a
legal concept in a way that the Intellectual Property community  
would accept.  I am fine with going with an alternative to the rule.   
As I have indicated, I think that  that there may other possible TLD
mechanisms that might have the same effect but which can not be defined
as RPMs.

thanks
a.



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

> 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