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:14:38 -0400

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