[gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on22April 2014

Luc SEUFER lseufer at dclgroup.eu
Tue Apr 22 13:06:51 UTC 2014


Hi Marika,

Thanks for the swift feedback (as always).

I also recall that the WG discussed the issue on multiple occasions, but I thought we agreed to give some room for manoeuvre to privacy/proxy providers until the eponym accreditation program is put together. With the proposed wording every party involved (complainant - UDRP provider - registrar) will have to cope with extra work each time a privacy/proxy provider will want to reveal the underlying data. Indeed, any such request will logically only happen after the 2 business days delay has passed and the respondent/proxy/privacy provider has been informed of the proceedings.

In my mind I thought we had recommended a more pragmatic approach but I may be wrong.

Luc

On Apr 22, 2014, at 13:14, Marika Konings <marika.konings at icann.org> wrote:

> Hi Luc,
>
> Re. your comment on 4 b, this is something that the WG did anticipate in
> its recommendation #3: 'In the case of accredited privacy / proxy
> Providers or a privacy / proxy provider affiliated with the registrar, the
> registrar may contact the accredited / affiliated privacy / proxy provider
> to allow for the reveal of the proxy customer data. However, such contact
> may only be established after an initial lock has been applied preventing
> any changes of registrar and registrant'. However, the WG did specify that
> this should only apply to accredited privacy / proxy providers following
> finalization of the privacy / proxy accreditation program by ICANN. So in
> other words, this is something that would need to be added / clarified
> either in the UDRP rules and/or the P/P policy once the privacy/proxy
> accreditation program is in place. If I recall well, the WG did discuss
> this issue extensively, but as in the current environment it is not always
> clear what is and what isn't a P/P service, it is not possible to
> establish any enforceable rules until the accreditation program has been
> finalised.
>
> Best regards,
>
> Marika
>
> On 22/04/14 12:22, "Luc SEUFER" <lseufer at dclgroup.eu> wrote:
>
>> Hi Matt and other working groupers,
>>
>> Yes, it should indeed read ³by registrant² in the lock definition as it
>> is the party that should be prevented from initiating any modification to
>> the domain name.
>>
>> As to 4 (b) I agree with Matt and also see another issue. The way it is
>> written now prevent the Registrar from notifying the Respondent of the
>> proceeding until the Lock measures have been applied. However, the
>> privacy/proxy provider (if any) is supposed to somehow learn about the
>> proceeding and provide the registrant underlying data before the Lock
>> measures are applied. In every case where the privacy/proxy provider will
>> be a different entity than the registrar, they won¹t know about the
>> proceedings and won¹t be able to terminate their service in a timely
>> fashion. Thus requiring the panel to review this request and delay the
>> proceedings.
>>
>> I may not be able to attend Today¹s meeting as it may conflict with
>> another meeting I have.
>>
>>
>> Best Wishes,
>>
>> Luc
>>
>>
>>
>> On Apr 15, 2014, at 2:29, Schneller, Matt
>> <Matt.Schneller at bgllp.com<mailto:Matt.Schneller at bgllp.com>> wrote:
>>
>> Hi Catitlin and everyone on the IRT,
>>
>> This looks great!  Two quick suggestions for everyone to mull over via
>> e-mail or on the call:
>>
>>
>> ·         In ³Lock,² should ³by the registrar² should be ³by the
>> Respondent² or perhaps ³by the Respondent or by the registrar²?
>>
>>
>>
>> ·         Do we need to add the bold text shown below in 4(b) to clarify
>> that the panel must decide what to do with post-Lock modification
>> requests?  Without ³requests for² it might imply that the modification
>> can be made (without approval) so long as the Panel retroactively decides
>> on the correctness of the request.
>>
>>
>> o   Any requests for modification(s) of the Respondent¹s data following
>> the two (2) business day period shall be addressed by the Panel.
>>
>> Thanks again for coordinating the process.  Best,
>>
>> Matt Schneller | Attorney | Bracewell & Giuliani LLP
>> 701 5th Avenue, Suite 6200, Seattle, WA 98104-7043
>> T: 206.204.6241 | F: 800.404.3970 | C: 206.679.1895
>> matt.schneller at bgllp.com<mailto:matt.schneller at bgllp.com> |
>> www.bgllp.com/schneller<http://www.bgllp.com/schneller>
>>
>>
>>
>> From:
>> gnso-impl-udrp-rt-bounces at icann.org<mailto:gnso-impl-udrp-rt-bounces at icann
>> .org> [mailto:gnso-impl-udrp-rt-bounces at icann.org] On Behalf Of Caitlin
>> Tubergen
>> Sent: Monday, April 14, 2014 2:18 PM
>> To: gnso-impl-udrp-rt at icann.org<mailto:gnso-impl-udrp-rt at icann.org>
>> Subject: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on 22
>> April 2014
>>
>> Hi All,
>>
>> The next Uniform Domain Name Dispute Resolution Procedure (UDRP)
>> Implementation Review Team meeting will be held on Tuesday 22 April 2014
>> at 1600 UTC.
>> 9:00PDT, 12:00EDT, 17:00London
>>
>> Adigo Conference ID: 28462745
>>
>> Adigo numbers: http://adigo.com/icann/
>>
>> Adobe Connect: https://icann.adobeconnect.com/udrp
>>
>> I have attached the second version of the revised UDRP Rules, which we
>> will discuss during the call.  The most recent changes, which were the
>> result of our last call, have been highlighted in yellow.  We will also
>> discuss implementation timelines, and how long the IRT feels is necessary
>> to implement these changes. Please let me know if you have any questions.
>>
>> Best regards,
>>
>> Caitlin Tubergen
>> Registrar Relations and Contracts Manager
>> ICANN
>>
>>
>>
>> _______________________________________________
>> gnso-impl-udrp-rt mailing list
>> gnso-impl-udrp-rt at icann.org<mailto:gnso-impl-udrp-rt at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-impl-udrp-rt
>>
>>
>> ________________________________
>>
>> --------------------------------------------------------
>>
>> This e-mail and any attached files are confidential and intended solely
>> for the use of the individual or entity to whom they are addressed. If
>> you have received this e-mail by mistake, please notify the sender
>> immediately and delete it from your system. You must not copy the message
>> or disclose its contents to anyone.
>>
>> Think of the environment: don't print this e-mail unless you really need
>> to.
>>
>> --------------------------------------------------------
>> _______________________________________________
>> gnso-impl-udrp-rt mailing list
>> gnso-impl-udrp-rt at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-impl-udrp-rt
>
> <default.xml>


________________________________

--------------------------------------------------------

This e-mail and any attached files are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail by mistake, please notify the sender immediately and delete it from your system. You must not copy the message or disclose its contents to anyone.

Think of the environment: don't print this e-mail unless you really need to.

--------------------------------------------------------


More information about the gnso-impl-udrp-rt mailing list