[PC-NCSG] Arguments Rejected

Fri Oct 2 17:40:00 EEST 2015

Hi Kathy,

That's exactly what's happening. On renewal agreements with .CAT, .PRO and .TRAVEL ICANN "negotiated" URS and other RPM's into the renewal agreements. Rather than properly create consensus policy on this issue through a PDP staff is creating de facto consensus policies through contract. If we don't stop this technique now the potency of the GNSO will forever be reduced.

Ed

Sent from my iPhone

> On Oct 2, 2015, at 3:28 PM, Kathy Kleiman <kathy at kathykleiman.com> wrote:
> 
> Ed,
> In that case, I agree completely. No, URS was never created as consensus policy for legacy TLDs. It was expressly, solely and completely adopted (in writing) as consensus policy only for New gTLDs. If it is being used beyond that, please stamp it out in every way possible.
> 
> Tx you,
> Kathy
> 
> :
>> Hi Kathy,
>> 
>> I believe that this is consensus policy relating to the new GTLD program. The issue here is that ICANN is taking this policy and extending it to legacy TLD's through contract. Perhaps I need a bit more education: was the URS ever made consensus policy for legacy TLD's? If it was then obviously I'm mistaken about the need for an Issues Report.
>> 
>> Thanks for clarifying,
>> 
>> Ed
>> 
>> Sent from my iPhone
>> 
>> On Oct 2, 2015, at 1:50 PM, Kathy Kleiman <kathy at kathykleiman.com> wrote:
>> 
>>> Hi Ed,
>>> If the URS is the Uniform Rapid Suspension, then it is consensus policy. It's original version, through the IRT was not (it came from IP interests), but then we demanded that it be thrown into the GNSO PDP process. It was an expedited process, but one in which all stakeholders were actively and aggressively represented. Our team was me, Konstantinos, Wendy and Robin. 
>>> 
>>> Others called it an "A Team" and we lived and breathed, fought for and won very extensive changes to the URS which are not part of the policy.
>>> 
>>> But perhaps there is another URS you are thinking of...
>>> Best,
>>> Kathy
>>> 
>>> :
>>>> Hi Rafik,
>>>> 
>>>> The URS is not consensus policy yet is being applied as such via contact. It would appear to me that the only way to tackle this problem would be to request an issues report on the URS use and hopefully have it rejected for use in legacy pdp's. If we ignore this issue and allow ICANN to continue to create de facto consensus policies by contract the role and position of the GNSO as the creator of consensus policies will be severely damaged.
>>>> 
>>>> I would appreciate thoughts of others of ways to turn back this staff encroachment on fundamental rights of the GNSO. We could go the Reconsideration / CEP/ IRP route, perhaps in association with others, but until that last costly option I'm not sure we would have a chance of success. An Ombudsman's complaint is also something we could consider.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Ed
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Oct 2, 2015, at 1:29 AM, Rafik Dammak <rafik.dammak at gmail.com> wrote:
>>>> 
>>>>> Hi Ed,
>>>>> 
>>>>> 
>>>>> 2015-10-02 0:59 GMT+09:00 Edward Morris <egmorris1 at toast.net>:
>>>>>> Hi Rafik,
>>>>>>> 
>>>>>>> thanks for the work done, wondering how to proceed here. I don't recall if there was any support at the public comment period.
>>>>>>> ? 
>>>>>> 
>>>>>> Lots. Phil Corwin and the BC actually led the charge on this issue against the IPC which had the the minority, and winning, view. It sort of makes one wonder about the public comment process.
>>>>>> 
>>>>>> We need to request an Issues Report on the URS. It's a bit risky in that it might legitimize a bad rpm tool but I don't think a Reconsideration would be worth the effort, although if someone has the time to do one I'd be happy to help. ? 
>>>>> 
>>>>> I thought there is already a report about all RPM https://www.icann.org/news/announcement-2015-09-11-en
>>>>> 
>>>>> Rafik? 
>>>>>> 
>>>>>>>> In other news, the Board chose Panama City as the host of next summers ICANN meeting. With the fall meeting in Puerto Rico that means our Meetings for next year will be held in two locations 1,100 miles from each other. London and Dublin, the sites for the next and last European meetings, are about 290 miles from each other. That is more diverse than our last two Latin American meetings prior to Panama City, both of which were held in Buenos Aires. To the extent ICANN's Meeting strategy is part of ICANN's global outreach strategy I would suggest it needs some work. ? 
>>>>>>> 
>>>>>>> well you can 2 times for ? Singapore. the last Asian city , which is not Singapore, was Beijing in ? 2013 ? . in fact it sounds with the meetings requirements, it become more harder different hosts. again wondering how it will be the new meeting format starting in 2016.
>>>>>> 
>>>>>> We need to ascertain what is going on here. It can't be exclusively cost; London and Dublin are expensive ? cities. I'll try to talk to Meetings staff in Dublin and see if I can get some background to share with everyone. The meetings are large but they are not the largest and other groups manage to find diverse locations. I was actually in favor of the Hub city strategy but if we are using the meetings, as argued, as part of the global outreach initiative...well, it's a big globe.
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> Ed
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Best,
>>>>>>> 
>>>>>>> Rafik
>>>>>>> 
>>>>>>>> A complete rundown of the Board's resolutions? from Monday? can be found here:? https://www.icann.org/resources/board-material/resolutions-2015-09-28-en#2.f? .
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> 
>>>>>>>> Ed
>>>>>>>> 
>>>>>>>> Sent from my iPhone
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> PC-NCSG mailing list
>>>>>>>> PC-NCSG at ipjustice.org
>>>>>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>>> 
>>>> 
>>>> _______________________________________________
>>>> PC-NCSG mailing list
>>>> PC-NCSG at ipjustice.org
>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>> _______________________________________________
>>> PC-NCSG mailing list
>>> PC-NCSG at ipjustice.org
>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ipjustice.org/pipermail/pc-ncsg/attachments/20151002/401abdaf/attachment-0001.html>