[gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on 22April 2014

Tue Apr 22 11:14:20 UTC 2014

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.xml
Type: application/xml
Size: 3222 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-impl-udrp-rt/attachments/20140422/6b245d05/default.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5056 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-impl-udrp-rt/attachments/20140422/6b245d05/smime.p7s>