<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-irtp-b-jun09] IRTP recommendation about locking during UDRP
- To: <tim@xxxxxxxxxxx>, "'Mike O'Connor'" <mike@xxxxxxxxxx>
- Subject: RE: [gnso-irtp-b-jun09] IRTP recommendation about locking during UDRP
- From: "Berry Cobb" <berrycobb@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 21 Jun 2011 19:33:51 -0700
I will mimic Marilyn's standard by stating that I am writing on my own
behalf and not that of the BC. In case you were not aware, I also
participated on the IRTP-B WG.
I will probably not shock anyone with my support of Mikey's view. This is
not the only recommendation where the issue of Policy Development vs.
Managing the Policy Process has surfaced. I reference the RAP
recommendation of a Non-Binding PDP on Best Practices of Malicious Use of
Domain Names. We have a proper GNSO sanctioned "pre-PDP" process that would
have acted as the framework in which to proceed, and that is what the WG
attempted to follow. Instead, the recommendation was watered down to a
"Discussion Paper" with no clear guidance on next steps. Correct me if I am
wrong, but I do not recall "Discussion Papers" in any part of the GNSO
process. I will not claim to be an expert in GNSO bylaws, but in my opinion
this is an adequate example where policy development at the Council bypassed
consensus of the WG recommendation. But, I digress.
Tim, you state that this IRTP recommendation is now folded in to the UDRP
Issues report. That's great, and HOPEFULLY a PDP will be approved.
However, what happens if a PDP on UDRP does not get approved by the council?
Now what? I'm speculating here, but "BLACK HOLE" comes to mind. And when I
see black holes the real result is that nothing gets fixed or accomplished
except a waste of time.
Lastly, I will take these experiences as a valuable learning lesson for
future PDP recommendations, if I am involved with such. WG members and
community participants MUST be more diligent in how we frame PDP
recommendations submitted to the Council. Further, WGs must provide more
clarity and less ambiguity of the recommendation and a suggested path on how
they should be executed.
I personally feel that if we do not course correct soon,the PDP process will
be in jeopardy of losing credibility.
Thank you for your time.
Berry Cobb
Infinity Portals LLC
berrycobb@xxxxxxxxxxxxxxxxxxx
http://infinityportals.com
720.839.5735
-----Original Message-----
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of tim@xxxxxxxxxxx
Sent: Tuesday, June 21, 2011 6:01 PM
To: Mike O'Connor
Cc: Gnso-irtp-b-jun09@xxxxxxxxx; bc-gnso@xxxxxxxxx;
stephane.vangelder@xxxxxxxxx; Mary.Wong@xxxxxxxxxxx
Subject: Re: [gnso-irtp-b-jun09] IRTP recommendation about locking during
UDRP
I'd rather not. I've explained it to you. You either don't get it or don't
want to. If you want to discuss F2F let me know.
Tim
-----Original Message-----
From: Mike O'Connor <mike@xxxxxxxxxx>
Date: Wed, 22 Jun 2011 08:54:44
To: <tim@xxxxxxxxxxx>
Cc: <Gnso-irtp-b-jun09@xxxxxxxxx>; <bc-gnso@xxxxxxxxx>;
<stephane.vangelder@xxxxxxxxx>; <Mary.Wong@xxxxxxxxxxx>
Subject: Re: [gnso-irtp-b-jun09] IRTP recommendation about locking during
UDRP
Tim, i'd much rather have this conversation over a limited-scope test-case
issue that's relatively straightforward to resolve than a really hard one.
if working groups are the place where policy gets made, then let the WG fix
this minor problem for you rather than fixing it yourselves.
On Jun 22, 2011, at 8:52 AM, tim@xxxxxxxxxxx wrote:
> Mikey,
>
> My record is pretty clear on process. I defend it fiercly. But you are
really blowing this out of proportion. If you are trainable, let it show.
Let's discuss further F2F.
>
> Best,
> Tim
>
> -----Original Message-----
> From: Mike O'Connor <mike@xxxxxxxxxx>
> Date: Wed, 22 Jun 2011 08:46:25
> To: <tim@xxxxxxxxxxx>
> Cc: <Gnso-irtp-b-jun09@xxxxxxxxx>; <bc-gnso@xxxxxxxxx>;
> <stephane.vangelder@xxxxxxxxx>; <Mary.Wong@xxxxxxxxxxx>
> Subject: Re: [gnso-irtp-b-jun09] IRTP recommendation about locking
> during UDRP
>
> you folks get to do whatever you want to do -- but like i said, i'm
trainable. if you as the Council are going to make that call, without
engaging the WG in the conversation, you're setting precedents that the
Council may come to regret when it is trying to recruit volunteers to devote
years of their lives to efforts like that in the future.
>
> all you have to do is ask us, rather than telling us.
>
> On Jun 22, 2011, at 8:40 AM, tim@xxxxxxxxxxx wrote:
>
>>
>> There is nothing for the WG to fix and the Council is not changing any
recs. We just want to consider that one with the UDRP issue it is already
tied in with. I am all for process, but we can protect that without
duplicating efforts.
>>
>> Tim
>>
>> -----Original Message-----
>> From: Mike O'Connor <mike@xxxxxxxxxx>
>> Date: Wed, 22 Jun 2011 08:18:32
>> To: Tim Ruiz<tim@xxxxxxxxxxx>
>> Cc: <Gnso-irtp-b-jun09@xxxxxxxxx>; <bc-gnso@xxxxxxxxx>;
>> <stephane.vangelder@xxxxxxxxx>; <Mary.Wong@xxxxxxxxxxx>
>> Subject: Re: [gnso-irtp-b-jun09] IRTP recommendation about locking
>> during UDRP
>>
>> yep -- i get that Tim. i'm really zeroed in on the process, though. it
would be fine to push it back to the WG with your comment as annotation.
this issue is the perfect one to use as a test-case for the very reasons you
describe. my worry is that some day we'll get to a tough/complex issue on
a WG report and the Council will roar off and try to fix it on the fly
rather than pushing it back to the people who've devoted the time to get up
to speed on the nuances.
>>
>> as a WG member i'd much rather hear "hey WG folks, can you fix this?"
than "we fixed it for you."
>>
>>
>> On Jun 22, 2011, at 7:54 AM, Tim Ruiz wrote:
>>
>>> Mikey,
>>>
>>> My goal is not to derail the rest of the work over this since that
>>> rec was already acted on. The locking question has already been
>>> picked up in the UDRP issues report (done in response to the RAP
report).
>>>
>>> Tim
>>>
>>>
>>>> -------- Original Message --------
>>>> Subject: [gnso-irtp-b-jun09] IRTP recommendation about locking
>>>> during UDRP
>>>> From: "Mike O'Connor"
>>>> Date: Tue, June 21, 2011 6:33 pm
>>>> To: "Gnso-irtp-b-jun09@xxxxxxxxx Mailing List"
>>>> , "bc-GNSO@xxxxxxxxx GNSO list"
>>>> , Tim Ruiz , Stéphane
>>>> Van Gelder , "Mary.Wong@xxxxxxxxxxx
>>>>
>>>> hi all,
>>>>
>>>> i'm just lobbing a suggestion into the "locking during
UDRP"-recommendation discussion that's going on in advance of the Council
meeting coming up later today. this note is primarily aimed at my
Councilors, colleagues in the BC and fellow members of the IRTP-WG, but i've
copied a few others just because i can.
>>>>
>>>> as a member of a working group that's wrapping up two years of work on
this stuff, i am hoping that the Council will not rewrite our
recommendations on its own. this is a repeat of the "i'm trainable" comment
i made in SFO. what i'm hoping is that the Council will vote the
recommendation up or down and, if it would like, sends the defeated
recommendation back to the working group for refinement. you can even
include suggestions if you like. but please don't make changes to our
recommendations without giving us a chance to participate in the process.
>>>>
>>>> you can invoke all the historic "Council should be *managing* the
policy process, not being a legislative body" arguments in this paragraph if
you like.
>>>>
>>>> i'm still trainable. :-)
>>>>
>>>> thanks,
>>>>
>>>> mikey
>>>>
>>>> - - - - -
>>>> phone 651-647-6109
>>>> fax 866-280-2356
>>>> web http://www.haven2.com
>>>> handle OConnorStP (ID for public places like Twitter, Facebook,
Google, etc.)
>>>
>>
>> - - - - - - - - -
>> phone 651-647-6109
>> fax 866-280-2356
>> web http://www.haven2.com
>> handle OConnorStP (ID for public places like Twitter, Facebook,
Google, etc.)
>>
>>
>
> - - - - - - - - -
> phone 651-647-6109
> fax 866-280-2356
> web http://www.haven2.com
> handle OConnorStP (ID for public places like Twitter, Facebook,
Google, etc.)
>
- - - - - - - - -
phone 651-647-6109
fax 866-280-2356
web http://www.haven2.com
handle OConnorStP (ID for public places like Twitter, Facebook, Google,
etc.)
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|