Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on 22 April 2014
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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller> From: gnso-impl-udrp-rt-bounces@icann.org [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@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
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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller> From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@icann.org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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. --------------------------------------------------------
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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@icann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-udrp-rt
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@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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@icann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@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. --------------------------------------------------------
In my recollection, we had not built in any additional time for privacy/proxy services that were not controlled by the Registrar because it was too big a question mark, but as Marika pointed out, we were going to allow the Privacy/Proxy Accreditation WG to develop a plan. What extra work do you think is proposed? If there is no lifting of the privacy service, the UDRP proceeds. If anyone want to do something after that point, they can, but the Provider and complainant are done at that point. That was the decision, as I recall it. Kristine -----Original Message----- From: gnso-impl-udrp-rt-bounces@icann.org [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Luc SEUFER Sent: Tuesday, April 22, 2014 8:07 AM To: Marika Konings Cc: gnso-impl-udrp-rt@icann.org Subject: Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on22April 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@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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@ icann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@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. -------------------------------------------------------- _______________________________________________ gnso-impl-udrp-rt mailing list gnso-impl-udrp-rt@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-udrp-rt
Hi Kristine, As I see it, if the proxy/privacy provider (i.e. the registrant of the domain name) isn’t informed of the complaint at the time of the verification but afterwards, the UDRP provider will need to review the request to modify the registrant data, the complainant will need to amend their complaint and the registrar will need to unlock the domain and appoint the applicable details upon instruction of the UDRP provider.( in accordance with paragraph 2 (e) of the UDRP rules) Luc On Apr 22, 2014, at 17:25, Dorrain, Kristine <kdorrain@adrforum.com> wrote:
In my recollection, we had not built in any additional time for privacy/proxy services that were not controlled by the Registrar because it was too big a question mark, but as Marika pointed out, we were going to allow the Privacy/Proxy Accreditation WG to develop a plan.
What extra work do you think is proposed? If there is no lifting of the privacy service, the UDRP proceeds. If anyone want to do something after that point, they can, but the Provider and complainant are done at that point. That was the decision, as I recall it.
Kristine
-----Original Message----- From: gnso-impl-udrp-rt-bounces@icann.org [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Luc SEUFER Sent: Tuesday, April 22, 2014 8:07 AM To: Marika Konings Cc: gnso-impl-udrp-rt@icann.org Subject: Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on22April 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@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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@ icann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@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.
-------------------------------------------------------- _______________________________________________ gnso-impl-udrp-rt mailing list gnso-impl-udrp-rt@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. --------------------------------------------------------
I just wanted to point out that the Final Report also noted that: 'Depending on the terms of service of the Proxy / Privacy service, a Registrar may opt to reveal underlying data as a result of privacy/proxy services to the Provider or in Whois, or both, if it is aware of such. This will not count as a “transfer” in violation of the above, if it occurs in accordance with draft recommendation #2. If a privacy/proxy service is revealed or proxy customer information released after the Lock is applied and the Provider is notified, the Provider is under no obligation to require the Complainant to amend its complaint accordingly, but may do so in its discretion'. Best regards, Marika On 22/04/14 18:03, "Luc SEUFER" <lseufer@dclgroup.eu> wrote:
Hi Kristine,
As I see it, if the proxy/privacy provider (i.e. the registrant of the domain name) isn’t informed of the complaint at the time of the verification but afterwards, the UDRP provider will need to review the request to modify the registrant data, the complainant will need to amend their complaint and the registrar will need to unlock the domain and appoint the applicable details upon instruction of the UDRP provider.( in accordance with paragraph 2 (e) of the UDRP rules)
Luc
On Apr 22, 2014, at 17:25, Dorrain, Kristine <kdorrain@adrforum.com> wrote:
In my recollection, we had not built in any additional time for privacy/proxy services that were not controlled by the Registrar because it was too big a question mark, but as Marika pointed out, we were going to allow the Privacy/Proxy Accreditation WG to develop a plan.
What extra work do you think is proposed? If there is no lifting of the privacy service, the UDRP proceeds. If anyone want to do something after that point, they can, but the Provider and complainant are done at that point. That was the decision, as I recall it.
Kristine
-----Original Message----- From: gnso-impl-udrp-rt-bounces@icann.org [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Luc SEUFER Sent: Tuesday, April 22, 2014 8:07 AM To: Marika Konings Cc: gnso-impl-udrp-rt@icann.org Subject: Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on22April 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@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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@ icann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@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.
-------------------------------------------------------- _______________________________________________ gnso-impl-udrp-rt mailing list gnso-impl-udrp-rt@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.
--------------------------------------------------------
Yes, this is my recollection. There is no required amendment after the lock/2 business days. If a privacy service comes up later, it's optional. -----Original Message----- From: Marika Konings [mailto:marika.konings@icann.org] Sent: Tuesday, April 22, 2014 11:12 AM To: Luc SEUFER; Dorrain, Kristine Cc: gnso-impl-udrp-rt@icann.org Subject: Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on22April2014 I just wanted to point out that the Final Report also noted that: 'Depending on the terms of service of the Proxy / Privacy service, a Registrar may opt to reveal underlying data as a result of privacy/proxy services to the Provider or in Whois, or both, if it is aware of such. This will not count as a "transfer" in violation of the above, if it occurs in accordance with draft recommendation #2. If a privacy/proxy service is revealed or proxy customer information released after the Lock is applied and the Provider is notified, the Provider is under no obligation to require the Complainant to amend its complaint accordingly, but may do so in its discretion'. Best regards, Marika On 22/04/14 18:03, "Luc SEUFER" <lseufer@dclgroup.eu> wrote:
Hi Kristine,
As I see it, if the proxy/privacy provider (i.e. the registrant of the domain name) isn't informed of the complaint at the time of the verification but afterwards, the UDRP provider will need to review the request to modify the registrant data, the complainant will need to amend their complaint and the registrar will need to unlock the domain and appoint the applicable details upon instruction of the UDRP provider.( in accordance with paragraph 2 (e) of the UDRP rules)
Luc
On Apr 22, 2014, at 17:25, Dorrain, Kristine <kdorrain@adrforum.com> wrote:
In my recollection, we had not built in any additional time for privacy/proxy services that were not controlled by the Registrar because it was too big a question mark, but as Marika pointed out, we were going to allow the Privacy/Proxy Accreditation WG to develop a plan.
What extra work do you think is proposed? If there is no lifting of the privacy service, the UDRP proceeds. If anyone want to do something after that point, they can, but the Provider and complainant are done at that point. That was the decision, as I recall it.
Kristine
-----Original Message----- From: gnso-impl-udrp-rt-bounces@icann.org [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Luc SEUFER Sent: Tuesday, April 22, 2014 8:07 AM To: Marika Konings Cc: gnso-impl-udrp-rt@icann.org Subject: Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on22April 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@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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@ icann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@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.
-------------------------------------------------------- _______________________________________________ gnso-impl-udrp-rt mailing list gnso-impl-udrp-rt@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.
--------------------------------------------------------
And to be clear, the UDRP will not be delayed. A Panel will consider the issue once it's appointed, but as a Panel is not yet appointed, it's not as though the issue is being reviewed as a preliminary matter. If the registrant is a proxy service and that doesn't lift by the time of the Lock, the Provider just proceeds. -----Original Message----- From: gnso-impl-udrp-rt-bounces@icann.org [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Marika Konings Sent: Tuesday, April 22, 2014 6:14 AM To: Luc SEUFER; Schneller, Matt Cc: gnso-impl-udrp-rt@icann.org Subject: Re: [gnso-impl-udrp-rt] Meeting invitation: UDRP IRT call on 22April 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@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@bgllp.com<mailto:Matt.Schneller@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@bgllp.com<mailto:matt.schneller@bgllp.com> | www.bgllp.com/schneller<http://www.bgllp.com/schneller>
From: gnso-impl-udrp-rt-bounces@icann.org<mailto:gnso-impl-udrp-rt-bounces@ic ann .org> [mailto:gnso-impl-udrp-rt-bounces@icann.org] On Behalf Of Caitlin Tubergen Sent: Monday, April 14, 2014 2:18 PM To: gnso-impl-udrp-rt@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org<mailto:gnso-impl-udrp-rt@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-udrp-rt
participants (4)
-
Dorrain, Kristine -
Luc SEUFER -
Marika Konings -
Schneller, Matt