[Gnso-rpm-providers] Actions & Notes: RPM Providers Sub Team 29 August 2018
Justine Chew
justine.chew at gmail.com
Fri Aug 31 03:49:11 UTC 2018
I would support a recommendation that the rule be amended/clarified such
that providers are required to utilize all three means of notice, and in
the interest of time, in the event
the Sub Team (or a majority thereof) supports the same, I will leave it to
Phil /co-chairs on how to best frame this for WG's consideration.
( And I shall no longer strictly consider ADNDRC to have not complied with
Rule 2(a) thus far. )
Regards,
Justine
-----
On Fri, 31 Aug 2018 at 11:07, 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-providers/attachments/20180831/16babf4c/attachment-0001.html>
More information about the Gnso-rpm-providers
mailing list