[Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team 29 August 2018
Michael Karanicolas
mkaranicolas at gmail.com
Fri Aug 31 16:16:34 UTC 2018
Hi,
I think that staff’s interpretation of 2(a) is incorrect based on the plain
language of the rules. It is extremely misleading to keep quoting the
phrasing “reasonably available means” without its proper context. *The very
next line* defines the scope of that responsibility as either being actual
notice – some sort of verification that the Respondent has seen the
complaint which, as others have pointed out, is an extremely difficult
standard along the lines of personal service – OR by using the three means
of communication listed: "sending the Notice of Complaint to all email,
postal- mail and facsimile addresses shown in the domain name's
registration data in the Whois database for the registered domain-name
holder, the technical contact, and the administrative contact, as well as
to any email 2 addresses for the Respondent provided by the Complainant".
This does not mean that the rule contemplates compliance in instances where
a provider only uses only one of the means of communication - as ADNDRC has
been doing - unless they can demonstrate that that means of communication
resulted in actual notice (i.e. personal service). So, unless ADNDRC can
demonstrate that all of the people they've emailed received actual notice
(which they obviously can't) - *they are in breach of the rules*.
I don't mean to belabour this issue - since I think we're ending up at a
similar place either way, and I would support either Phil's language or an
amendment clarifying the existing requirement to use all three means of
communications in the absence of actual notice. But I feel the need to
point this out since these interventions are not helpful if they push the
discussion in misleading directions.
Best,
Michael
On Aug 31, 2018, at 12:07 AM, Mary Wong <mary.wong at icann.org> wrote:
Hello Justine and everyone,
Staff recalls that there was some discussion previously (either within this
Sub Team or among the broader Working Group) regarding the scope of Rule
2(a). From the face of the text, it seems that Rule 2(a), as written
currently, does *not* mandate that providers must use all three forms of
communication (i.e. email, post, fax), in that all it requires is that the
providers use “reasonably available means calculated to achieve actual
notice”. While a provider that uses all three means will be deemed to have
achieved actual notice, the rule seems to contemplate compliance in
circumstances where a provider may have used only one or two out of the
three means.
Given Brian’s, Phil’s and others’ feedback, staff would like to ask if the
Sub Team (or a majority thereof) supports retaining what seems to be the
current scope, or wishes to recommend that the rule be amended/clarified
such that providers are required to utilize all three means of notice.
We hope this clarifies the question.
Thanks and cheers
Mary, Julie & Ariel
*From: *Gnso-rpm-providers <gnso-rpm-providers-bounces at icann.org> on behalf
of Justine Chew <justine.chew at gmail.com>
*Date: *Thursday, August 30, 2018 at 22:48
*To: *"gnso-rpm-providers at icann.org" <gnso-rpm-providers at icann.org>
*Subject: *Re: [Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team
29 August 2018
Brian,
No one is advocating for guaranteed actual notice. What I am saying is we
should not leave interpretation of Rule 2(a) to the Providers as they
'please', and that moving forward it is understood that ICANN Compliance
should monitor and enforce Rule 2(a) in the way it was intended to be
interpreted - from my perspective, that is that all Providers are required
to send Notices of Complaint not only by email, by also by fax and
postal-mail where those details are available in WHOIS, and specifically
that ADNDRC's practice be brought in line with FORUM and MFSD's.
In other words, Phil has very eloquently hit the nail on its head with his
last sentence, "For all those reasons, I think we should enforce the
existing requirements for three methods of providing notice, but not
mandate actual notice as that can never be guaranteed even with best
efforts." Thank you, Phil!
I merely wanted to re-confirm the above in my original intervention.
Regards,
Justine
-----
On Fri, 31 Aug 2018 at 04:23, Martin Pablo Silva Valent <
mpsilvavalent at gmail.com> wrote:
It really sounds that Phill got it right for all.
Cheers,
Martín
On 30 Aug 2018, at 16:33, Corwin, Philip via Gnso-rpm-providers <
gnso-rpm-providers at icann.org> wrote:
My personal view is that, as Mary suggested, “Rule 2(a) should really just
require all three forms of notice, so that "actual notice" can be deemed to
have been achieved”. We can’t expect providers to send out agents to
physically locate domain registrants and ask them F2F if they received
notice.
As Brian notes, in some cases registrants deliberately provide false
contact information because they know the are registering and using domains
in bad faith and don’t want to be identified. In other cases, and this will
occur more as new gTLDs age, the original contact data was correct but it
hasn’t been updated and now the fax number has changed or been
disconnected, the email address is no longer used and checked, and they
have moved from the original physical address without leaving forwarding
information.
Also, while default rates in URS are high, they are almost as high for UDRP
and I don’t recall seeing much if any anecdotal information about
registrants who provided correct contact data not getting actual notice in
UDRP practice. Another consideration is that, if there is a failure to
deliver notice in a timely manner, the URS consequence is less harsh
(domain suspension, not extinguishment or transfer) and the opportunities
for post-default rehearing are more generous.
For all those reasons, I think we should enforce the existing requirements
for three methods of providing notice, but not mandate actual notice as
that can never be guaranteed even with best efforts.
Philip S. Corwin
Policy Counsel
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
703-948-4648/Direct
571-342-7489/Cell
*"Luck is the residue of design" -- Branch Rickey*
*From:* Gnso-rpm-providers [mailto:gnso-rpm-providers-bounces at icann.org
<gnso-rpm-providers-bounces at icann.org>] *On Behalf Of *BECKHAM, Brian
*Sent:* Thursday, August 30, 2018 7:04 AM
*To:* Justine Chew <justine.chew at gmail.com>; Mary Wong <mary.wong at icann.org>
*Cc:* gnso-rpm-providers at icann.org
*Subject:* [EXTERNAL] Re: [Gnso-rpm-providers] Actions & Notes: RPM
Providers Sub Team 29 August 2018
Thanks Mary, and Justine,
Again, if I may, observing this subteam, I would point out that actual
notice in all cases would simply be an impossible standard.
Despite clear obligations on registrants to provide accurate contact
details -- which are in turn supposed to be vetted by registrars -- notably
including an email address (for an Internet-based domain name
registration), not infrequently registrant's (intentionally) use false
contact details.
I imagine that these factors significantly underpin the standard of
"reasonable means" (or actual notice) in seeking to effect notice.
Brian
------------------------------
*From:* Gnso-rpm-providers <gnso-rpm-providers-bounces at icann.org> on behalf
of Justine Chew <justine.chew at gmail.com>
*Sent:* Thursday, August 30, 2018 5:48 AM
*To:* Mary Wong
*Cc:* gnso-rpm-providers at icann.org
*Subject:* Re: [Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team
29 August 2018
Hi Mary,
In reply to your question, my answer is "I would have thought so" but given
the responses herein, I read Susan's proposed wording to focus on
monitoring and ensuring compliance which is good, but the point I queried
has to do with interpretation of Rule 2(a), as in to what needs to be
complied with. And as we can see, this differs from person to person, even
with the Providers -- with Forum and MSFD seeming to have read it one way
and ADNDRC another.
So, question is, if at all, what does this subteam want to do about having
ICANN Compliance (and everyone else) interpret Rule 2(a) "correctly".
Regards,
Justine
-----
On Thu, 30 Aug 2018 at 11:31, Mary Wong <mary.wong at icann.org> wrote:
Hello everyone,
If staff may be permitted to provide input here, is the fundamental
question whether Rule 2(a) should mandate actual notice, versus what it now
says, which is that all the providers are obliged to do is use "reasonably
available means calculated to achieve actual notice"? At the moment, this
is deemed to be fulfilled if they indeed send postal and electronic and fax
notices - so the related question is whether or not Rule 2(a) should really
just require all three forms of notice, so that "actual notice" can be
deemed to have been achieved.
If this is a specific recommendation the Providers Sub Team wishes to make,
staff can certainly add it to the Super Consolidated Table.
On the question of ADNDRC compliance with Rule 2(a) - wouldn't the need to
investigate this now be incorporated in Susan's proposed wording?
Thanks and cheers
Mary, Julie & Ariel
On 8/29/18, 16:46, "Gnso-rpm-providers on behalf of Michael Karanicolas" <
gnso-rpm-providers-bounces at icann.org on behalf of mkaranicolas at gmail.com>
wrote:
Yes - I think the wording is problematic, for precisely that reason.
It includes a particular procedure for notification, but then suggests
that this may be an alternative to "actual notice"... how on earth is
ADNDRC supposed to affirm that they provided actual notice in the URS
timeframe? Especially given the default rates (which don't necessarily
mean that the all these respondents HAVEN'T been getting notice... but
certainly don't support an implication that they have). I think it's
illogical to interpret the wording as meaning that postal notice is
optional - but the phrasing of it sort of provides an outlet if
providers aren't properly fulfilling their responsibility.
Fundamentally though - I think we are in agreement that ADNDRC should
be doing this, right?
On Wed, Aug 29, 2018 at 3:00 PM Justine Chew <justine.chew at gmail.com>
wrote:
>
> ...2(a) ...Achieving actual notice, or employing the following
measures to do so, .....
> (i) sending the Notice of Complaint to all email, postal-mail and
facsimile addresses shown in the domain name's registration data in the
Whois database ....
>
> ADNDRC's response didn't give me a right comfort level that actual
notice was achieved 100% of the time, and as you say, 2(a) is to ensure
that the Provider has taken all reasonable steps to achieve actual notice,
which should include postal-mail and fax delivery of the Notice of
Complaint.
>
> So, now I wonder if the language in 2(a) needs revisiting. But I'll
leave that thought to percolate.
>
> Justine
> -----
>
>
> On Thu, 30 Aug 2018 at 01:39, Susan Payne <susan.payne at valideus.com>
wrote:
>>
>> Well, I don’t think I was the only one, but I certainly do think
that it has not been established beyond doubt that ADNDRC are actually in
breach – if they have managed in all their cases to effect actual notice by
the means they have utilised, then they have met their obligations under
2(a):
>>
>> “2(a) When forwarding a Complaint, including any annexes,
electronically to the Respondent, it shall be the Provider's responsibility
to employ reasonably available means calculated to achieve actual notice to
Respondent. Achieving actual notice, or employing the following measures to
do so, shall discharge this responsibility…”
>>
>> However, given that some domain registrants will not submit a
response, the various means set out at 2(a) are there to ensure that the
Provider has taken all reasonable steps to ensure they are aware. And
based on the answers we got from ADNDRC it does not seem as though they are
set up to utilise the other means of service.
>>
>>
>>
>>
>>
>> Susan Payne
>> Head of Legal Policy | Valideus Ltd
>>
>> E: susan.payne at valideus.com
>> D: +44 20 7421 8255
>> T: +44 20 7421 8299
>> M: +44 7971 661175
>>
>>
>>
>> From: Justine Chew [mailto:justine.chew at gmail.com]
>> Sent: 29 August 2018 18:27
>> To: Susan Payne <susan.payne at valideus.com>
>> Cc: Julie Hedlund <julie.hedlund at icann.org>;
gnso-rpm-providers at icann.org
>> Subject: Re: [Gnso-rpm-providers] Actions & Notes: RPM Providers Sub
Team 29 August 2018
>>
>>
>>
>> That works for me, Susan, thanks.
>>
>> Just digressing a little. You triggered a memory .... I recall
someone in the RPM WG (but can't recall who now) who interpreted the URS
Rule 2(a) loosely such that if a Provider thought email and only email is a
reasonable means calculated to achieve actual notice to Respondents then
that would be allowable. I don't think there is any merit to this
interpretation. I believe URS Rule 2(a) is quite clear on the 2-fold
obligation on the part of Providers, so I don't think there is a need to
tighten the language in URS Rule 2(a).
>>
>>
>> Regards,
>>
>> Justine
>> -----
>>
>>
>>
>>
>>
>> On Thu, 30 Aug 2018 at 01:09, Susan Payne <susan.payne at valideus.com>
wrote:
>>
>> Regarding my action item, how about:
>>
>>
>>
>> ICANN Compliance
>>
>>
>>
>> ICANN Compliance should be responsible for monitoring URS providers
to ensure that they operate in accordance with the administrative
requirements of the URS and URS Rules, including, by way of example,
requirements as to method, language and timing of communications and the
publication of required information .
>>
>>
>>
>> In view of the expedited nature of URS proceedings, ICANN Compliance
should work with the URS Providers and relevant registries to rapidly
address and resolve any incidences of registry non-compliance with
obligations relating to registry locking/unlocking and suspension.
>>
>>
>>
>> Susan Payne
>> Head of Legal Policy | Valideus Ltd
>>
>> E: susan.payne at valideus.com
>> D: +44 20 7421 8255
>> T: +44 20 7421 8299
>> M: +44 7971 661175
>>
>>
>>
>> From: Gnso-rpm-providers [mailto:gnso-rpm-providers-bounces at icann.org]
On Behalf Of Julie Hedlund
>> Sent: 29 August 2018 14:42
>> To: gnso-rpm-providers at icann.org
>> Subject: [Gnso-rpm-providers] Actions & Notes: RPM Providers Sub
Team 29 August 2018
>>
>>
>>
>> Dear All,
>>
>>
>>
>> Please see below the action items and notes captured by staff from
the Providers Sub Team call held on 29 August 2018 (12:00-13:30 UTC).
Staff have posted to the wiki space the action items and notes. Please
note that these will be high-level notes and are not meant as a substitute
for the recording. The recording, AC chat, and attendance records are
posted on the wiki at:
https://community.icann.org/display/RARPMRIAGPWG/2018-08-29+Sub+Team+for+URS+Providers
.
>>
>>
>>
>> See also the attached referenced documents.
>>
>>
>>
>> Best Regards,
>>
>> Julie
>>
>> Julie Hedlund, Policy Director
>>
>>
>>
>> ==
>>
>>
>>
>> ACTION ITEMS:
>>
>>
>>
>> Susan Payne will suggest language for an overarching recommendation
concerning the need for ICANN Compliance proactive monitoring.
>> Staff will update the Super Consolidated URS Table with the
suggested edits agreed to by the Sub Team shown in redline. Note in the
cover email that staff has inserted additional language in the Education
and Training section at the direction of the Sub Team. Ask for responses
by COB Friday and if no objections the redlined document will be accepted
by COB Friday.
>>
>>
>>
>> NOTES:
>>
>>
>>
>> Operational Fixes:
>>
>>
>>
>> A. THE COMPLAINT
>>
>>
>>
>> 4. Administrative review
>>
>>
>>
>> A URS provider should check the websites of other URS and UDRP
providers to ensure that a disputed domain name is not already subject to
an open/active URS/UDRP proceeding.
>>
>>
>>
>> -- I think registrant is in the best position, but I'm assuming it's
not difficult for the providers to check?
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> 6. Amending the Complaint in light of GDPR/Temp Spec -- page 5/6
>>
>>
>>
>> Providers should modify their operational rules in terms of
automatically populating the Complaint Form using WHOIS data.
>>
>> -and-
>>
>> GDD, [Providers, and Registries] should [jointly] develop a uniform
system for interaction between the Providers and the Registries regarding
registrant data that is unavailable in publicly accessible WHOIS
>>
>> [rules for the timely response by Registries to requests for
non-public information from Providers]
>>
>>
>>
>> -- Not what sure we are suggesting -- what do we mean by "develop a
uniform system for interaction" -- do we mean a system for timely response
from the Providers?
>>
>> -- Accept the suggested revised language with strikeouts and
additional text in brackets.
>>
>>
>>
>> B. NOTICE
>>
>>
>>
>> 1. Receipt by Registrant - Notice (feedback from Complainant &
Respondent)
>>
>>
>>
>> ADNDRC should change its operational rules to comply with URS
Procedure 4.2, requiring that notice of the Complaint be transmitted [with
translation] by the registrant via email, fax, and postal mail.
>>
>>
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> 2. Effect on Registry Operator - Notice requirements for Registry
Operators
>>
>>
>>
>> ICANN’s email addresses for Registry contacts (reached by Providers)
should be kept up to date
>>
>> -and-
>>
>> GDD, [Providers, and registries] should [jointly] develop a uniform
system for interaction between the Providers and the Registries regarding
Registry notice requirements
>>
>>
>>
>> -- What does "(reached by Providers)" mean? Strike the
parenthetical and change to "should be kept up to date for use by
Providers".
>>
>> -- Accept the suggested revised language with additional text in
brackets.
>>
>>
>>
>> F. REMEDIES
>>
>>
>>
>> 3. Review of Implementation
>>
>>
>>
>> There should be efforts undertaken to better inform and enhance the
understanding by Registry Operators and Registrars of their role in the URS
process
>>
>>
>>
>> -- Accept the suggested revised language
>>
>> ACTION ITEM: Susan Payne will suggest language for an overarching
recommendation concerning the need for ICANN Compliance proactive
monitoring.
>>
>>
>>
>> J. LANGUAGE ISSUES
>>
>>
>>
>> 1. Language issues, including current requirements for complaint,
notice of complaint, response, determination
>>
>>
>>
>> ICANN should enforce the URS Rules 9 and URS Procedure 4.2 with
respect to Providers communicating with the Registrant in the predominant
language of the Registrant. In particular, as the WG has found that ADNDRC
is not in compliance with URS Procedure 4.2 and URS Rules 9, ICANN should
request ADNDRC to change their operational rules and to translate the
Notice of Complaint “into the predominant language used in the Registrant’s
country or territory”.
>>
>>
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> M. URS PROVIDERS
>>
>>
>>
>> 1. Evaluation of URS providers and their respective processes
(including training of panelists)
>>
>>
>>
>> Provider compliance with URS Rule 6(a) should be enforced. ADNDRC,
in particular, should be required to list the backgrounds of all of their
Examiners so that Complainants and Respondents can check for conflicts of
interest.
>>
>>
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> Policy Proposals:
>>
>>
>>
>> A. THE COMPLAINT
>>
>>
>>
>> 6. Amending the Complaint in light of GDPR/Temp Spec
>>
>>
>>
>> URS Rule 3(b) should be amended in light of GDPR and the permissible
filing of a “Doe Complaint”.
>>
>> -and-
>>
>> URS Procedure para 3.3 should be amended to enable modification of
the Complaint within 2-3 days from disclosure of the full registration data
by the URS Provider.
>>
>> -and-
>>
>> Outreach and education efforts should be undertaken via expert
intermediaries to increase awareness and understanding of the common law
concept of “Doe Complaint” in civil law jurisdictions, especially the EU.
>>
>>
>>
>> -- Accept the suggested revised language.
>>
>> -- Re: "WG to communicate with the EPDP Team about this issue:
European civil law systems do not recognize the common law concept of "Doe
Complaint", and the concept is not well understood in Europe" This could
be addressed in an informal note.
>>
>>
>>
>> B. NOTICE
>>
>>
>>
>> 1. Receipt by Registrant -Notice (feedback from Complainant &
Respondent)
>>
>>
>>
>> For “Doe Complaints’, Providers should [first] send notice to
respondents [via the online registrant contact form and then by the
required methods] as soon as relevant WHOIS data is forwarded by the
registry.
>>
>>
>>
>> -- Accept the suggested revised language with additional text in
brackets.
>>
>>
>>
>> E. DEFENSES
>>
>>
>>
>> 1. Scope of Defenses
>>
>>
>>
>> 2. Unreasonable delay in filing a complaint (i.e. laches)
>>
>>
>>
>> All Providers should provide similar types and forms of guidance to
their examiners.
>>
>> -and-
>>
>> Examiners should document their rationale in all issued
Determinations; in particular, when an Examiner finds that a registrant has
registered and used a domain in bad faith supporting facts should be cited.
>>
>>
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> F. REMEDIES
>>
>>
>>
>> 2. Duration of Suspension Period
>>
>>
>>
>> 3. Review of Implementation
>>
>>
>>
>> URS Technical Requirements 3 and Registry Requirement 10 should be
amended, [and compliance efforts should be directed,] to address problems
with the implementation of the relief awarded following a URS decision; the
implementation of a settlement (generally a domain transfer at the
registrar level); and implementation of Complainant requests to extend a
suspension.
>>
>>
>>
>> -- Do we need to mention ICANN Compliance role at all? Reword
accordingly.
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> K. ABUSE OF PROCESS
>>
>>
>>
>> 1. Misuse of the process, including by trademark owners, registrants
and “repeat offenders”
>>
>>
>>
>> Penalties for the abuse of the process by the Respondent should be
added to the URS Rules; this proposal should be published to solicit public
comment on what type of procedural abuse should be sanctioned, and in what
manner.
>>
>>
>>
>> -- Don't think that anything discussed in the Providers Sub team to
support or oppose this notion. We could seek public comment on it.
>>
>> -- Our "position" could be that this examination be for both
Complainant and Respondent for fairness. But okay to action item to WG
rather than as a recommendation.
>>
>> -- Create a new section 3: Suggested Action Items: The WG should
consider whether to include the following question in the Initial Report
for the purpose of soliciting public comment: “Are penalties for abuse of
the process by the Complianant or Respondent sufficient, or if not, or
should they be expanded, and how?"
>>
>> -- Accept the suggested approach.
>>
>>
>>
>> Re: "WG to consider whether, in light of FORUM and MFSD feedback on
use of WHOIS to help determine Respondent language, policy recommendations
should be developed to handle language and related GDPR concerns."
>>
>>
>>
>> -- Not sure why this should be a concern since the information about
the country should be available.
>>
>> -- Agree GDPR should not be a concern insofar as country of
Registrant is concerned.
>>
>> -- Change from a recommendation to an action.
>>
>>
>>
>> L. EDUCATION & TRAINING
>>
>> 1. Responsibility for education and training of complainants,
registrants, registry operators and registrars
>>
>>
>>
>> ICANN [should] develop easy-to-understand, multilingual, and
linkable guidance (e.g. basic FAQs) for reference and informational
purposes of both URS parties (Complainants and Respondents)
>>
>> -and-
>>
>> URS Providers should develop additional clear and concise reference
and informational materials specific to their service, practice, and
website for the use and benefit of both URS parties.
>>
>>
>>
>> -- Accept the suggested revised language.
>>
>>
>>
>> M. URS PROVIDERS
>>
>> 1. Evaluation of URS providers and their respective processes
(including training of panelists)
>>
>>
>>
>> Explicit standards for [for the sanction and removal of Examiners
should be considered” removal of Examiners based upon particular background
and factors, such as continued representation of serial cybersquatters, or
representation of parties found to have engaged in attempted reverse domain
name hijacking, should be developed.
>>
>>
>>
>> -- I don't think we identified that there was a problem.
>>
>> -- Reword "Explicit standards for the sanction and removal of
Examiners should be considered." Put into Section 3, Suggested Action Items.
>>
>> -- Accept the suggested revised language with strikeouts and
additional text in brackets.
>>
>> _______________________________________________
>> Gnso-rpm-providers mailing list
>> Gnso-rpm-providers at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rpm-providers
>
> _______________________________________________
> Gnso-rpm-providers mailing list
> Gnso-rpm-providers at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rpm-providers
_______________________________________________
Gnso-rpm-providers mailing list
Gnso-rpm-providers at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rpm-providers
World Intellectual Property Organization Disclaimer: This electronic
message may contain privileged, confidential and copyright protected
information. If you have received this e-mail by mistake, please
immediately notify the sender and delete this e-mail and all its
attachments. Please ensure all e-mail attachments are scanned for viruses
prior to opening or using.
_______________________________________________
Gnso-rpm-providers mailing list
Gnso-rpm-providers at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rpm-providers
_______________________________________________
Gnso-rpm-providers mailing list
Gnso-rpm-providers at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rpm-providers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-providers/attachments/20180831/50257adb/attachment-0001.html>
More information about the Gnso-rpm-providers
mailing list