[gnso-rpm-wg] FOR REVIEW/DISCUSSION - NEW co-chairs' statement on additional RPMs, and UPDATED table of TMCH Charter questions

Greg Shatan gregshatanipc at gmail.com
Wed Dec 7 12:08:46 UTC 2016

I'm not saying I disagree with all of the Co-Chairs' conclusions.  I just
wish they weren't so conclusive.  I do, however, disagree with the two
paragraphs I cited.

Taking private RPMs into account in our work can be valuable in doing our
Charter-mandated work, and I support the Co-Chairs' conclusion there..
Asserting jurisdiction over private RPMs, however, goes beyond our Charter
and I would not support that.

I understand there's a balance between facilitating a discussion and
advocating a conclusion.  A good portion of the letter achieves that
balance, and perhaps I was too harsh in making blanket statements; I value
the Co-Chairs' hard work and bringing the issues to our attention. Again
however, I feel that the two cited paragraphs go too far (perhaps because
the conclusion is a big stretch) in setting out only one analysis and
conclusion about the scope of our remit.

On Wed, Dec 7, 2016 at 3:28 AM Kiran Malancharuvil <
Kiran.Malancharuvil at markmonitor.com> wrote:

I agree with J. Scott.  We must examine private RPMs.  Some of the
justification used for rejecting certain policies was related to
implementation feasibility.

These RPMs prove that those arguments need to be revisited.



*Kiran Malancharuvil*

Policy Counselor


415.222.8318 (t)

415.419.9138 (m)


*From:* gnso-rpm-wg-bounces at icann.org [mailto:gnso-rpm-wg-bounces at icann.org]

*On Behalf Of *J. Scott Evans

*Sent:* Wednesday, December 07, 2016 12:24 AM

*To:* Greg Shatan <gregshatanipc at gmail.com>

*Cc:* gnso-rpm-wg at icann.org

*Subject:* Re: [gnso-rpm-wg] FOR REVIEW/DISCUSSION - NEW co-chairs'
statement on additional RPMs, and UPDATED table of TMCH Charter questions

Well Greg, I cannot say we always agree.


First, I am disappointed in your tone and implied accusation that the
Co/Chairs are somehow abusing our position. I do not think that is the
case. Our broad Charter is to review the RPMs to see if they are
functioning as designed and having

the desired effect. Private RPMs play a part in this analysis. I stand by
our letter.

Sent from my iPhone

On Dec 7, 2016, at 1:21 AM, Greg Shatan <gregshatanipc at gmail.com> wrote:

I found the Co-Chairs' statement somewhat troublesome.  First, I felt that
it advocated for particular outcomes, which

both strains the bounds of chair neutrality and takes a top-down approach
inconsistent with bottom-up development of WG positions (which is given a
brief mention at the very end of the letter, but only after the advocacy
has played out).  It might have been

preferable to present the questions without the answers and allowed the WG
to develop its position, rather than laying out a position that essentially
becomes a default position.

That said, I have some sympathy for the idea the group should take notice
of the private RPMs in trying to review, analyze and potentially modify the
ICANN-created RPMs -- even

if I don't think that position should have been spoon-fed to the WG.

I have significantly more trouble with two paragraphs in the letter, which
go beyond taking notice of the private RPMs, to asserting WG jurisdiction
over the private RPMs.

I don't buy the argument that these are within the scope of this group;
re-reading the Charter just confirmed my view. This is an aggressive
attempt at "bootstrapping" from the remit of this group to reach into areas
well out of scope.

The first of these paragraphs is:

The WG inquiry may also consider whether, and to what extent, additional
protective services should be consistent with either policy decisions
reflected in the shaping of the ICANN-required RPMs (noting that it may

have always been contemplated that such RPMs could constitute a “floor” and
not an overall limitation on additional market-provided protections) or
with the recognized scope of trademark law. For example, should a rights
holder be able to block the registration

of unlimited variations of its registered mark, and should one trademark
owner be able to block the registration of a mark that another has
equivalent rights to for separate classes of goods and services?

To the contrary, the WG has no authority to opine on or to create policy
for private RPMs -- unless the Charter is significantly amended (which I
can't see supporting).  The second troublesome paragraph is:

The Co-Chairs also wish to better understand the process, if any, by which
registry operators gain approval for the offering of such additional RPMs.
Section 2.1 of the standard new gTLD registry agreement permits

a registry operator to offer Registry Service that is an Approved Service,
but requires it to request approval under the Registry Services Evaluation
Policy (RSEP) if it wishes to offer any service that is not an Approved
Service or is a material modification

of an Approved Services. It is important for the WG to understand whether
registry-offered RPMs, especially those based upon TMCH mark registrations,
have been subject to any such approval review and, if so, what criteria
were utilized in their evaluation.

I think this goes even a step further than the first paragraph in a couple
of ways.  First, the issue of how and whether private RPMs should be
approved seems even further beyond

the scope of this WG.  Second, it advocates for a particular view and
interpretation of both the registry agreement and the nature of private
RPMs.  I'm also a bit skeptical that this is propose just for the WG to
"understand" what happened.  RSEP requests

are public, as far as I know, so it would be readily evident whether any
private RPMs were the subject of an RSEP request.  Of course, even that
question assumes too much.  If we find ourselves delving into questions
involving registry agreements, the parameters

of Registry Services and Approved Services, the nature of private RPMs, and
the triggers that require the RSEP process, then I think we've lost our way.

Since this is only a draft statement, I would encourage the Co-Chairs to
revise the statement to exclude these two paragraphs.  Frankly, I would
prefer it if the second draft

was nothing more than a set of questions, but this first draft is something
that can't be unseen....


On Mon, Dec 5, 2016 at 3:25 AM, Mary Wong <mary.wong at icann.org> wrote:

Dear all,

In advance of the Working Group call this week, and pending circulation of
the finalized agenda, please find attached the following documents for your
review and further discussions:

(1) A draft statement from our Working Group co-chairs regarding the
provision of additional rights protection mechanisms by the TMCH and
registry operators (i.e. in addition to the minimum mandatory RPMs
prescribed by ICANN and which form the basis of our

current Policy Development Process); and

(2) A table of all the TMCH-related Charter questions, as refined and
suggested by the Sub Team and including notes and questions from several
Working Group members as of 4 December. This document essentially
replicates the Proposed Edited Questions that were

circulated in the form of the more comprehensive table that was discussed
by the Sub Team, but hopefully aids your deliberations as it sets out all
the proposed questions in one spot.

Thanks and cheers


On 12/5/16, 07:52, "gnso-rpm-wg-bounces at icann.org on behalf of George
Kirikos" <gnso-rpm-wg-bounces at icann.org on behalf of

icann at leap.com> wrote:

    I think the 2nd formulation of Question #15 is better, as it's more

    open-ended, yet also asks for specifics on how concerns can be


    As an aside, the "Original Question" of #15 suggested "of course with

    a central database" --- there's no technical reason why a central

    database would be required. There could instead be multiple

    independent databases, which registrars and/or registries could query

    in parallel via a standardized API. There'd only need to be a central

    *list* of which TMCH providers needed to be queried. From a coding

    perspective, the registrar/registry could simply query the entire list

    of providers, and collate the results.

    Most registrars already have this technology/capability, as they often

    query multiple registries (and secondary marketplaces) in parallel

    when customers attempt a new domain name registration (e.g. customer

    searches for EXAMPLE.COM, but they'll query not only the

    Verisign-operated .com registry, but also .net/org/biz/info/us and

    hundreds of other TLDs, marketplaces like Sedo/Afternic, and they'll

    even generate and query variations of "EXAMPLE.TLD" for availability,

    presenting the customer with a list of hundreds of alternatives).


    George Kirikos



    On Sun, Dec 4, 2016 at 12:25 PM, David Tait <david.tait at icann.org>

    > Dear All




    > In advance of the meeting of the Rights Protection Mechanisms Working

    > on Wednesday at 1800 UTC, I am pleased to enclose the updated review
of the

    > TMCH Charter questions which has been prepared by the Sub-Team tasked

    > conduct an initial review of these questions.




    > Staff have been expressly asked to draw your attention to Question
15. Two

    > possible formulations of this question have been prepared and the

    > is seeking the view of the Working Group as to which of these should

    > adopted.




    > Kind regards,




    > David Tait




    > David A. Tait


    > Policy Specialist (Solicitor qualified in Scotland, non-practicing)


    > Internet Corporation for Assigned Names and Numbers (ICANN)




    > Mobile: + 44-7864-793776


    > Email:  david.tait at icann.org


    > www.icann.org



    > _______________________________________________

    > gnso-rpm-wg mailing list

    > gnso-rpm-wg at icann.org




    gnso-rpm-wg mailing list

    gnso-rpm-wg at icann.org



gnso-rpm-wg mailing list

gnso-rpm-wg at icann.org



gnso-rpm-wg mailing list

gnso-rpm-wg at icann.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20161207/ad5e49b6/attachment-0001.html>

More information about the gnso-rpm-wg mailing list