[Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team 29 August 2018
Martin Pablo Silva Valent
mpsilvavalent at gmail.com
Fri Aug 31 17:25:28 UTC 2018
I tend to agree with Michael here, and in any case, I think Phill’s comments really finds a middle ground and a sensible proposal.
Best,
Martín
> On 31 Aug 2018, at 13:16, Michael Karanicolas <mkaranicolas at gmail.com> wrote:
>
> 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 <mailto: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 <mailto:gnso-rpm-providers-bounces at icann.org>> on behalf of Justine Chew <justine.chew at gmail.com <mailto:justine.chew at gmail.com>>
>> Date: Thursday, August 30, 2018 at 22:48
>> To: "gnso-rpm-providers at icann.org <mailto:gnso-rpm-providers 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
>>
>>
>>
>> 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 <mailto: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 <mailto: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 <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 <mailto: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 <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 <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 <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 <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 <mailto:Gnso-rpm-providers at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-rpm-providers <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 <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/7f9ae7ea/attachment-0001.html>
More information about the Gnso-rpm-providers
mailing list