[Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team 29 August 2018
Cyntia King
cking at modernip.com
Thu Aug 30 20:09:21 UTC 2018
Good points, Phil.
Cyntia King
O: +1 816.633.7647
C: +1 818.209.6088
From: Gnso-rpm-providers <gnso-rpm-providers-bounces at icann.org> On Behalf Of Corwin, Philip via Gnso-rpm-providers
Sent: Thursday, August 30, 2018 2:34 PM
To: brian.beckham at wipo.int; justine.chew at gmail.com; mary.wong at icann.org
Cc: gnso-rpm-providers at icann.org
Subject: Re: [Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team 29 August 2018
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] On Behalf Of BECKHAM, Brian
Sent: Thursday, August 30, 2018 7:04 AM
To: Justine Chew <justine.chew at gmail.com <mailto:justine.chew at gmail.com> >; Mary Wong <mary.wong at icann.org <mailto:mary.wong at icann.org> >
Cc: gnso-rpm-providers at icann.org <mailto: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 <mailto:gnso-rpm-providers-bounces at icann.org> > on behalf of Justine Chew <justine.chew at gmail.com <mailto:justine.chew at gmail.com> >
Sent: Thursday, August 30, 2018 5:48 AM
To: Mary Wong
Cc: gnso-rpm-providers at icann.org <mailto: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 <mailto: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 <mailto:gnso-rpm-providers-bounces at icann.org> on behalf of mkaranicolas at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto:julie.hedlund at icann.org> >; gnso-rpm-providers at icann.org <mailto: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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-providers/attachments/20180830/b9488cb9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5366 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-rpm-providers/attachments/20180830/b9488cb9/image001-0001.jpg>
More information about the Gnso-rpm-providers
mailing list