[gnso-rpm-wg] URS Missing Topics and Further Thoughts

George Kirikos icann at leap.com
Wed Aug 15 16:53:03 UTC 2018


Hi Renee,

There are services that run on a webserver which renew the 3-month SSL
certficates automatically, so no human intervention is required. If
you research the topic more, it's not hard.

Sincerely,

George Kirikos
416-588-0269
http://www.leap.com/


On Wed, Aug 15, 2018 at 12:41 PM, Fossen, Renee <rfossen at adrforum.com> wrote:
> In response to George's issue:
>
> 8) Remedies, F.4. HSTS - as I noted on the call, this isn't a registry
> issue; the providers simply need to have HTTPS suspension pages, to
> complement the HTTP suspension pages. This is trivial to implement by
> providers. If they can't do it, they can outsource it to those with
> the technical capabilities (I know I could do it, if I had to, using
> the widely used tools that are available for HTTPS versions of sites).
>
> FORUM has been communicating with ICANN on this issue.  ICANN has provided FORUM with a redline draft URS Service Provider Technical Guidance document.
>
> While FORUM can obtain free wildcard SSL certificates through https://letsencrypt.org/ [letsencrypt.org], the process of obtaining and installing these certificates is very manual.  The certificates expire after only 3 months, thus requiring continual renewal. FORUM may have hundreds of domains subject to URS suspensions at any particular point in time. As FORUM reads the draft Technical Guidance document, FORUM will be required to support HTTP and HTTPS for *all* suspended domains, not just those on the HSTS-preload list.  FORUM has requested clarification on this issue.
>
> An added complication is the potential lack of communication from the Registry and accuracy of the registration expiration date, post GDPR.  It has been FORUM’s experience that the registration date information pulled from Whois, does not match the information ultimately received from the Registries and Registrars upon verification.  Forum has no way to know when and if the information is actually correct, to enable it to track the status of the suspended domain.
>
> As FORUM indicated in its responses to the initial set of questions from the WG, very few communications are received from the Registry regarding the expiration of the registration or deletion dates.  In order for FORUM to manage the renewal of SSL certificates it will need to receive and track all status information from the Registry in light of the potential for inaccurate Whois registration information.   As FORUM has not been required to devote such resources to the suspension page, FORUM will likely be required to hire and train additional resources to handle this process – especially if it is required to do so for all suspended domains, not only those on the HSTS-preload list.
>
> Kind regards,
>
> Renee Fossen
> Director of Arbitration
>
> FORUM
> 6465 Wayzata Blvd., Suite 480
> Minneapolis, MN  55405
> Phone  952.516.6456
> E-mail  rfossen at adrforum.com
> www.adrforum.com
>
>
>
> -----Original Message-----
> From: gnso-rpm-wg [mailto:gnso-rpm-wg-bounces at icann.org] On Behalf Of George Kirikos
> Sent: Sunday, August 12, 2018 11:31 AM
> To: gnso-rpm-wg
> Subject: [gnso-rpm-wg] URS Missing Topics and Further Thoughts
>
> Hi folks,
>
> In response to Wednesday's email:
>
> https://mm.icann.org/pipermail/gnso-rpm-wg/2018-August/003209.html
>
> where WG members were "requested to provide substantive comment and
> raise anything they believe is missing"
>
> here are my thoughts. The single most important point below is item
> #9, as I raised on the conference call last Wednesday, namely the
> issue of external court proceedings.
>
> For reference, the Initial Consolidated URS Topics Table is at:
>
> https://community.icann.org/download/attachments/79432641/URS%20Docs_ICANN61.pdf?version=1&modificationDate=1520631910000&api=v2
>
> 1) Page 3 (of Initial Consolidated URS Topics): Do the RPMs adequately
> address issues of registrant protection (such as freedom of expression
> and fair use)?
>
> This issue appears to have been skipped entirely in the Super
> Consolidated URS Topics Table (perhaps not surprisingly, given that
> registrants weren't canvassed, and practioners' survey was dominated
> by those representing complainants). This needs to be addressed,
> including overall Due Process (i.e. the "such as" above are merely
> examples, but not a complete list of the issues for registrants)
>
> 2) Complaint, A.3 (Limited Filing Period). The topic of a "statute of
> limitations" fits into this topic, and needs to be addressed by the
> working group. These limitation periods exist under national laws, and
> complainants should not have rights in the URS that exceed those they
> would have under national laws. A 2 year limitation period should be
> adopted (2 years after creation date) for the URS (that would match
> Ontario's jurisdiction, for example, where I reside.
>
> 3) Response, C.1 (Duration of response period). Disagree with draft
> recommendation that "No additional policy work required". When you
> mainly hear from complainants, providers and those representing
> complainants, that's the kind of skewed result that happens.
> Registrants need sufficient time to respond, and 14 days is inadequate
> (as evidenced by the high number of defaults, which is also
> interrelated with the issue of the language issue, e.g. a Chinese
> registrant receiving an English notice and/or complaint!). This also
> relates to point #2 above -- all the "time limits" are applied
> unequally on respondents, and never to complainants. There needs to be
> a better balance. While pro-complainant side might be opposed to this,
> as it would reduce "rapidity" or URS, it's already a relatively slow
> mechanism (i.e. the fastest way to suspend a site is to complaint to a
> registrar or ISP/hosting provider, and also use blocking mechanisms
> such as Google's Safebrowsing initiative, see:
> https://safebrowsing.google.com/ )
>
> Depending on how the statute of limitations policy outcome, the policy
> could also allow for a longer response time based on the age of a
> domain (measured from creation date). There is no urgency for a
> dispute regarding a 10-year old domain (and if there was, TM holders
> still have the alternative to go to court and seek an injunction).
>
>
> 4)  Standard of Proof, D.1. Disagree with the "finding" that "RPM is
> being used for 'clear case of abuse' as it was intended", given that
> the practioners surveyed were mainly those representing complainants.
> We know that decisions in favour of complainants are being made even
> when the domain name hasn't been *used* in bad faith (i.e. hasn't been
> used at all), for common terms (e.g. acronyms, dictionary words,
> surnames, etc.). e.g. see BCG.app decision
> http://www.adrforum.com/domaindecisions/1785973D.htm Panelists are
> finding "passive holding" abuse, when they shouldn't be (i.e. when
> there are multiple potential uses for a domain). OpenCorporates.com,
> for example, shows many potential legitimater users of "BCG" that are
> unrelated to Boston Consulting Group. Similarly, AcronymFinder.com
> shows multiple matches unrelated to Boston Consulting Group.
>
> 5) Defenses, E.2. Unreasonable delay in filing a complaint (i.e.
> laches). Laches is a somewhat *separate* issue from Statute of
> limitations (discussed in point #2 above). With statute of
> limitations, if you've delayed, regardless of whether it's
> "reasonable" or not, you lose the right to use the procedure. A
> respondent need only point to the calendar itself, rather than provide
> an argument as to whether it's "fair" or not. Under "laches", a
> respondent would have to do more work, e.g. saying that circumstances
> have change, evidence is no longer available, etc. "Statute of
> Limitations" is a much cleaner implementation, reducing the potential
> abuse of "no laches" discretion by panelists/providers (who are in the
> business of making money from complaints, unlike courts). With statute
> of limitations, there is no discretion (you snooze, you lose!).
>
> 6) Defenses, E.2: Issues 3/4/7 (minimal standards, whether they've
> been met, policing existing rules) don't seem to have any
> recommendations. At a minimum, there needs to be a way to remove bad
> panelists, to hold them accountable. Particularly since the
> Complainant picks the provider -- forum shopping can arise, if many
> "bad" panelists are at a single provider ("bad" = biased towards
> complainants, in that case). There needs to be an oversight of the
> providers themselves by either ICANN, or a complaints
> organization/community appointed and empowered by ICANN (perhaps made
> up of a representative panel from the community, including registrants),
> to be able to decertify panelists/providers. It should not be
> "accredit and forget it".
>
> 7)  Remedies, F.1. Proposed suggestion was left blank, but would be
> opposed to a transfer option, right of first refusal, or affecting the
> drop catching system (i.e. deletion cycle of domains). What I would
> support would be a mediation system that would allow for a transfer
> (as part of a negotiations) at an early stage, before time/money is
> spent on panelists adjudicating a dispute. This would save everyone
> time/money, as shown in the Nominet case. We need to look at
> restructuring the "flow chart" for exactly how the URS (and later the
> UDRP) proceeds, to really try to encourage these kinds of outcomes. It
> would take too long to describe it here, but there should be very
> early "Notice of Disputes" (in a succinct form, saving money for
> complainants), that could then allow for quick mediation, followed by
> longer complaints if those fail or if the registrant doesn't respond,
> with appropriate appeals mechanisms too). Potentially, there could be
> integration with the UDRP itself into a single policy.
>
> 8) Remedies, F.4. HSTS - as I noted on the call, this isn't a registry
> issue; the providers simply need to have HTTPS suspension pages, to
> complement the HTTP suspension pages. This is trivial to implement by
> providers. If they can't do it, they can outsource it to those with
> the technical capabilities (I know I could do it, if I had to, using
> the widely used tools that are available for HTTPS versions of sites).
>
> 9) Appeal, G.1. The topic of external court proceedings (from the
> Initial Consolidated URS Topics Table) was missed completely, perhaps
> inadvertently because it slipped onto a separate page from the other
> points of G.1 (i.e. the question differentiated between internal
> mechanisms and external ones). The "Super Consolidated" document skips
> the external mechanisms completely.
>
> As I noted when I first brought the issue to the RPM PDP mailing list
> in November 2017:
>
> https://mm.icann.org/pipermail/gnso-rpm-wg/2017-November/002585.html
>
> and as David Maher followed up on CircleID:
>
> http://www.circleid.com/posts/20180103_the_udrp_and_judicial_review/
>
> this is a critical issue for registrants (and applies to both
> URS/UDRP). Conceivably it could be addressed in a Stage 2 along with
> the UDRP, but it must be *knowingly* deferred to that stage, i.e. it
> can't be considered a topic that we've "solved" in this stage 1. [we
> might want to create a list of topics that we are *knowingly* shifting
> to stage 2]
>
> Some had suggested that ICANN can't "create a cause of action". That
> misses the point of this issue completely. ICANN shouldn't have
> written a policy in the first place that had this flaw, which
> *assumed* that registrants would be able to have heard in court in
> court on the merits de novo.
>
> The root cause of this issue is the "role reversal" that takes place.
> A domain registrant defends a URS/UDRP as a respondent. But, if the
> registrant wants to take an adverse decision to court, then they'd
> become the *complainant*. Had the URS/UDRP never existed, the TM
> holder would always be the complainant (and have a cause of action,
> e.g. TM infringement, cybersquatting, etc.), and the registrant would
> be the defendant (and have defenses). But, when the roles are switched
> unnaturally (because the URS/UDRP came first), the registrant may not
> have a "cause of action" to bring the court case, thus breaking the
> implicit bargain underlying the URS/UDRP that these complement
> existing laws, and didn't exist to replace those mechanisms.
>
> The obvious solution is to restore the TM holder to their natural role
> as  "complainant" in the courts, and have the registrant be the
> defendant in the courts (i.e. eliminate the role reversal). There are
> examples from other
> systems we can adopt. For example in the case of the DMCA and YouTube,
> I noted that role reversal doesn't happen:
>
> https://mm.icann.org/pipermail/gnso-rpm-wg/2018-January/002669.html
>
> i.e. content creator makes a counter-notification, and says:
>
> ""I consent to the jurisdiction of the Federal District Court for the
> district in which my address is located, or if my address is outside
> of the United States, the judicial district in which YouTube is
> located, and will accept service of process from the claimant."
>
> (can adapt this to the domain case, to say registrant will consent to
> a case filed in their own jurisdiction or that of the registrar)
>
> One could adopt the solution from the IGO PDP, namely to vitiate the
> URS decision in the event there's no cause of action for a registrant.
> But, there's actually an even better solution (which came too late to
> be considered by that PDP), see the discussion of "Option #7" I started at:
>
> https://mm.icann.org/pipermail/gnso-igo-ingo-crp/2018-June/001226.html
>
> In British Columbia, Canada, they have a "Civil Resolution Tribunal" to steer
> small claims court cases and condo disputes to an online tribunal. A
> key part of their process, which we can follow, is their "Notice of Objection":
>
> https://civilresolutionbc.ca/how-the-crt-works/how-the-process-ends/#what-i=
> f-i-dont-agree-with-the-decision
>
> "If you disagree with the CRT's final decision on a small claims
> matter, including a default decision, you can pay a fee and file a
> Notice of Objection with the CRT. The Notice of Objection must be
> filed within 28 days after a party receives a CRT decision. The CRT
> cannot issue an order in a small claims dispute until the deadline for
> filing a Notice of Objection expires.
>
> If a Notice of Objection is filed, the CRT decision is not
> enforceable. If any party wants to continue any of the claims that
> were included in the dispute, that party must file a Notice of CRT
> Claim in the BC Provincial Court. The CRT will provide a Certificate
> of Completion to all the parties. The Certificate of Completion must
> be included with the Notice of CRT Claim, or the Provincial Court
> registry will not accept it.
>
> Here are some things about the Notice of CRT Claim process that you should
> know:
>
> It's like an appeal and you will get a new process with the BC
> Provincial Court, including a settlement conference or pre-trial
> conference and a trial
> The Small Claims Rules specify which Provincial Court registry the
> Notice of CRT Claim must be filed in
> Once filed, the filing party must serve the Notice of CRT Claim on the
> other parties
> The Provincial Court may order a party to pay a deposit for some or
> all of the amount of the CRT decision
> If the person who filed the Notice of Objection does not have a better
> outcome in the BC Provincial Court than in the CRT's decision, the BC
> Provincial Court may order that party to pay a penalty to the other
> party"
>
> So, in the domain context, a URS (or UDRP) registrant who doesn't like
> the outcome can pay a fee and file a Notice of Objection.  To prevent
> gaming, the size of that fee should be comparable to what it would cost the
> registrant in court fees to file a court case (which can then be
> refunded once they've filed a statement of defense). The fee acts a
> sort of security or performance bond, that they will indeed defend the
> matter in court. That bond can be forfeited to the TM
> holder/complainant, in the event the registrant defaults on their
> promise to show up and defend in court.
>
> This completely solves the role reversal at the root cause of the
> problem, as it's the TM holder who will always be filing the court
> case as plaintiff, just as they would had the URS/UDRP not existed.
> And it further reduces gaming, because the court could take into
> account the URS outcome when assessing costs (see above, where it says
> "If the person who filed the Notice of Objection does not have a
> better outcome in the BC Provincial Court than in the CRT's decision,
> the BC Provincial Court may order that party to pay a penalty to the
> other party.")
>
> 10. G.2. De novo review: Practitioners survey results are obviously
> one-sided about removing de novo review, given the fact that there was
> only 1 practitioner who had represented registrants. I cannot
> overemphasize the lack of statistical validity of that survey (it was
> both (1) an unrepresentative and (2) small sample). A balanced survey
> that had those representing registrants with equal weight would not
> have yield such silly results. I challenge anyone who thinks the size
> of the survey was valid to use the margin of error calculator at:
> https://www.surveymonkey.com/mp/margin-of-error-calculator/  and send
> us the results (along with your inputs). Even with a (unrealistically
> low) population size of 34, 95% confidence level, and sample size of
> 14, we're talking about a +/- 20% margin of error! That's huge.
> [someone had suggested that 14/34 = 41% response rate to the survey was
> good --- obviously that informal comment doesn't match the formal
> statistical results from that calculator as to true error margins]
>
> 11. Cost Allocation Model, G1. Unlike some who have a registrants's
> perspective on these issues, I am 100% in favour of a loser pays
> system,  provided
> it's carefully constructed to ensure that it will reduce frivolous
> complaints (and penalize obvious cybersquatters). I think some on the
> registrant side of the issue might believe the system is too tilted in
> favour of complainants at this time to permit it to be fairly
> implemented, which is a valid concern. Nonetheless, I think we should
> explore this more deeply. I think everyone would agree that we want to
> root out bad actors on *both sides* of the disputes (i.e. bad
> complainants, who bring complaints that are frivolous, as well as
> cybersquatters). There needs to be effective recourse to the courts
> too, as systems of checks/balances though (see point #9 above), in the
> event that these "costs" awards get misapplied by providers/panelists.
> We shouldn't summarily dismiss this topic.
>
> Conceivably, the cost allocation need not fall only upon the registrants
> themselves, but instead on bad registrars/registry operators, where
> high levels of abuse seem to be tolerated. e.g. see Spamhaus TLD abuse
> (for spam, but there's likely a correlation to TM abuse too):
>
> https://www.spamhaus.org/statistics/tlds/
>
> When more than 50% of some domains "seen" are "bad domains", that's an
> obvious registry issue. I could envision some sort of refundable
> security bond/pool by registrars/registries, which is not refunded if
> there's excessive amount of cybersquatting originating from their
> registrar/registry.
>
> 12. J.1. Language. There's a huge "English" predisposition or even
> bias in this PDP (my own language is English, for the record). Sites
> like nTLDstats.com show how a large proportion of new gTLD
> registrants/registrars are from countries where English is not the
> dominant language (e.g. China). We have to do a lot better on this, to
> ensure that registrants are not disadvantaged by
> receiving notices and/or complaints that they simply can't understand.
>
> 13. N.1. We should continue to talk about mediation, and also possible
> integration as a single (multi-step) process in the UDRP itself.
>
> 14. Seems to have disappeared from our radar, but we appeared to have
> general agreement on standardized XML formats for decisions. This
> should be somewhere in our initial report (perhaps defer to stage 2,
> to consider with UDRP too?).
>
> For example,
>
> https://gnso.icann.org/sites/default/files/file/field-file-attach/transcript-rpm-review-09may18-en.pdf
>
> page 21:
>
> George Kirikos: Yes. Long ago I proposed that UDRP or URS decisions be
> available in XML format, like a machine-readable format, for the ease
> of academic research. I was wondering if you could talk a little bit
> about how much this kind of research costs you in terms of time and
> money and manual entry of data, et cetera and how much time and money
> you would have saved had the decisions, et cetera been available
> through machine-readable format? Thank you.
>
> Kathy Kleiman: And Rebecca, briefly too if you could.
>
> Rebecca Tushnet:I’m going to let (Alex) - yes. I'm going to - because
> she is - so it is her work and her labor that is at issue here and so,
> (Alex), do you have any
> thoughts?
>
> (Alex Noonan): So XML would have been incredible. Berry did
> a great job pulling a lot of these fields for us so some of them were
> easily scrapeable, but there are some that are important that weren't.
> So it took a lot of time to paste in the representative information.
> The country information, that kind of stuff is interesting. Like I
> would have expected a lot of these to be coming from China but as a
> matter of fact a lot of them were coming from the United States. That
> kind of stuff was valuable but really hard to get. On average it took
> me approximately six minutes to code each one of these and because the
> decisions are so short, a good bit of that was copying and pasting of
> stuff. That actually wasn't academic work. So I think in the end it
> was like - it was a substantive effort but XML would have been
> incredible and made it so much easier."
>
> And before that in January 2018:
>
> https://gnso.icann.org/sites/default/files/file/field-file-attach/transcript-rpm-review-17jan18-en.pdf
>
> pp.22-23
>
> George Kirikos: George Kirikos for the transcript. Yes. I've been
> advocating exactly that for, you know, at least a decade now with
> regards to the (EDRP) and of the data - applies to the URS. The
> community can come up with the standard XML format for publication of
> decisions that would have all the relevant fields and the providers
> would be expected to publish in that format. So, it's not hard but it
> needs to be the policy requirement in order get them in line. Thanks.
>
> J. Scott Evans: Okay. I am seeing general agreement with that. So, if
> we could note that in our notes that it appears that the
> recommendation - one of the recommendations that we'd feel like we
> should make at the end of this process is with regards to at least at
> this stage, the URS that there should be standardized reports
> developed and that each provider should have to provide in a
> standardized format so that as George pointed out, we're getting the
> same information from everyone and that makes it easy for researchers
> to look at the data and make sure we're getting the same data. Okay.
> George is making the point in the chat that he's not just talking
> about a standardized report, he's also talking about how the decisions
> are formatted and he sees them in an XML format because that would
> make it easier to actually work with the data.
>
> https://mm.icann.org/pipermail/gnso-rpm-wg/2018-January/002700.html
>
> (AC chat PDF, starting at the bottom of page 3, going to page 5)
>
> I don't know how this "disappeared", but I'm not the one "holding the
> pen" in this PDP.
>
> 15. It's not clear if this is the right time for us to put forth
> recommendations yet, but I would call for elimination of the URS, as
> its benefits to a very narrow group simply don't exceed its costs (on
> registrants, registry operators, and registrars). I can expand on this
> later, but did want to put this on the record (I assume we'll have
> ample time to make formal proposals like this, same as when Jeremy for
> example proposed elimination of Sunrise). Briefly, when new gTLDs were
> being considered, some folks predicted huge waves of cybersquatting,
> which required new RPMs as a countermeasure. Like many folks making
> predictions about new gTLDs, their predictions were completely wrong.
> Since those predictions were wrong, the policy outcomes of the past
> that were based on those incorrect predictions should be undone.
>
> We've probably spent more money (in terms of the opportunity cost
> associated with reviewing the URS, adding up both paid ICANN staff and
> also unpaid volunteer time from the community) than the total benefits
> from this procedure.
>
> The complaints themselves are dominated by the world's richest
> companies, who can certainly afford to either use the UDRP or the
> courts instead.
>
> In terms of "costs", there are real compliance costs for registrants,
> registrars, and registries who are subject to these policies. As a
> prospective registrant, I have to take into account the applicability
> of a burdensome RPM when considering whether to purchase a new gTLD
> domain, and weigh that against other alternatives. I think part of the
> lower than expected demand for new gTLDs can be explained by these
> excess regulatory burdens, and registrars/registries would see higher
> volumes of registrations for their products if these burdens were
> removed. Registrars/registries would also see lower costs, as there
> would simply be less red tape.
>
> I would suggest alternative approaches that would have a greater
> **deterrent** effect on bad actors, to replace the URS procedure. e.g.
> as a responsible registrant, I would have no problems posting a
> security bond or providing some other "signal" (e.g. public WHOIS,
> verified WHOIS, certification of some form, etc.), perhaps based on
> volume of registrations (those with 100+ domains, etc.). Bad actors
> (serial cybersquatters, etc.) would have much more difficulty
> providing that kind of "signal". One could even allow folks to
> explicitly opt-out of various RPMs, based on their providing these
> signals (i.e. they'd still be subject to court action, but could lower
> their compliance costs by providing suitable signals that they're not
> a bad actor). Some "reputation" based scheme could be developed, that
> could allocate higher costs to higher-risk actors, just like insurance
> and other systems of risk management do.
>
> One need only look at the SpamHaus stats I posted above, and see that
> URS has no impact on the huge amounts of actual abuse that occurs in
> these TLDs. A more effective alternative approach that will target
> high volume abusers is really required to replace this ineffective
> policy.
>
> As I said before, we all want to root out the bad actors. Let's find
> the right way to do it, and look beyond the ineffective solutions of
> the past.
>
> Sincerely,
>
> George Kirikos
> 416-588-0269
> http://www.leap.com/
> _______________________________________________
> gnso-rpm-wg mailing list
> gnso-rpm-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg


More information about the gnso-rpm-wg mailing list