[Gnso-newgtld-wg-wt4] Registry Services straw-person

Tue Sep 5 20:52:29 UTC 2017

Rubens,
I have communicated separately with you off-list and to Leadership regarding your response.  The following comments are circulated to the entire list:

A.      Please circulate the second Straw Proposal in addition to your own for comparison purposes.  The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition:   “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services:  LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).

B.      You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services.  However, it is in fact your Straw Proposal that suggests such additional fees are appropriate.  If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.

C.      You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4.  If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.)  How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?

Again, I believe the three issues which must be clearly outlined and discussion facilitated are:

1.       Should new registry services be proposed in the application itself or at any stage chosen by the applicant, including at contracting and after contracting?  Why are we changing the time of evaluation of proposed new registry services when the existing application says “Additional proposed registry services that are unique to the registry must also be described.”?  Do registries prefer this be a discussion that occurs only between contracting parties and ICANN?

2.       What existing services should be pre-approved for the  next round?  Does it include idn registrations and RPMs with blocking? (Here do we mean idn registrations within the application for a non-idn Top Level Domain or something else?  If both are recommended, how does Sub Pro alert the RPM PDP as to the possible implications for RPM policy?)  And how can Sub Pro stay on course and recommend moving forward to the next round if it creates policy issues that RPM PDP has not yet been able to address?)

3.       Should applicants pay fees for evaluation of proposed new services even if  no Technical Panel is needed?  Why is this being changed from the process followed in the 2012 round?  Isn’t this proposed change in fact creating a policy issue because the entire purpose of unlimited gTLDs was to encourage innovation and competition?

Thank you,
Anne

Anne E. Aikman-Scalese

Of Counsel

520.629.4428 office

520.879.4725 fax

AAikman at lrrc.com<mailto:AAikman at lrrc.com>

_____________________________

[cid:image002.png at 01D3264E.36824D10]

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 700

Tucson, Arizona 85701-1611

lrrc.com<http://lrrc.com/>

From: Rubens Kuhl [mailto:rubensk at nic.br]
Sent: Tuesday, September 05, 2017 12:36 PM
To: Aikman-Scalese, Anne
Cc: Jeff Neuman; gnso-newgtld-wg-wt4 at icann.org
Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Em 5 de set de 2017, à(s) 15:38:000, Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>> escreveu:

Jeff,
Thanks for your note.  I certainly don’t see a problem with charging fees if a Technical Panel has to be called in – in other words, maintain the status quo in this regard.  With respect to maintaining the status quo, my understanding of the existing Application Question is that it states as follows:

It is actually a bit different than that, i'll explain that below.

23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
A.   Receipt of data from registrars concerning registration of domain names and name servers.
B.   Dissemination of TLD zone files.
C.   Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
D.   Internationalized Domain Names, where offered.
E.   DNS Security Extensions (DNSSEC). The applicant must describe whether any of
these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.  (Emphasis added by me.)

You indicated that both Straw proposals would be discussed and considered.  Later Sarah and I received a redline of the existing (Rubens) proposal  from Kurt Pritz which he said Rubens had asked him to prepare.   That redline raises additional issues.  For example, it says that preapproved services will include

I can't comment on it while it has not been posted on the list, so if Sarah, Kurt and you believe it's ready I encourage all to send it to the list... just as reference, the latest straw-person (which as I said I don't think it's a one's person proposal since it's already in its 4th generation after many suggestions) was sent to the list by me September 1, 1331 UTC.

(a)    IDN registrations.  (permitting IDN registrations raise issues of customer confusion.

Those issues of customer confusions are already address in the IDN Guidelines, a document that was the primary reference during the 2012-round and still is.

It also raises trademark Sunrise issues since many TM owners hold idn trademark registrations for their English marks. )

I don't recall any suggestion during the IDN discussions to stop provisioning IDN registration services due to TM issues... and that would contradict years of ICANN efforts in that regard. Anyway, that would be on-topic for the RPM PDPs WG, not for Subsequent Procedures...

(b)    “additional marketplace Rights Protection Mechanisms that have been identified as “blocks”.  (I find myself wondering whether Avri has any comments on this in her personal capacity.  I may really like this but it doesn’t change the procedural aspect of what we are doing.)
(c)    Bulk Transfer After Partial Portfolio Acquisition (BTPPA).  (Sorry I don’t know what a “BTPPA” service is.)

Curiously one piece news including BTPPA surfaced after the call, and it can give a first glimpse on what BTPPA is:
http://domainnamewire.com/2017/09/01/namecheap-sues-enom-tucows-demands-transfer-4-million-domains/

The original Verisign BTAPPA request can be found here:
https://www.icann.org/en/system/files/files/verisign-btappa-request-29jul09-en.pdf

So we have more to discuss than the two Straw Person proposals put forward.  We also need to discuss the preapproved services.

Since at least one of them mentioned pre-approved services, we can discuss that while discuss the straw person(s)...

Charging  fees for evaluation of additional services is not the only policy issue.

And while it's a policy issue, it's not a WT4 issue...

There is also a policy issue as to which point in time the proposed services will be evaluated.  My proposal says proposed new services should be included in the application phase for proper transparency and evaluation at that time. (This seems to be the case in the existing version of Question 23.)

The redline circulated by Kurt to me and Sarah (apparently at Ruben’s request),

The only message I sent was sent to the list; no message was sent by me to any of 3 and no request to be passed along was made. The only suggestion I did, during the call and after in the list, was for those said they are willing to propose something different, to compile something and send it to the list.

says the applicant can choose at what stage it wants the new services to be evaluated.  So as I see it , there are three clear policy issues that must be discussed here:

1.       Should new registry services be proposed in the application itself or at any stage chosen by the applicant, including at contracting and after contracting?  Why are we changing the time of evaluation of proposed new registry services when the existing application says “Additional proposed registry services that are unique to the registry must also be described.”?  Do registries prefer this be a discussion that occurs only between contracting parties and ICANN?

Actually, we identified that some registries could prefer discussing at application time, contracting time or after contracting depending on their preferred balance of predictability, time to market and innovativeness of the service.
Note that we would be adding one intermediary option, at contracting; both application time and after contracting were options already available in the 2012-round, and would continue to be available.

2.       What existing services should be pre-approved for the  next round?

Possibly the same services that would be pre-approved for all gTLD registries by then. But we could establish which services at a minimum should be there, similar to what we are doing with bundled technical evaluation and the RSP program.

Does it include idn registrations and RPMs with blocking?

Certainly IDN registrations, since it's the most prolific registry service request there is.

3.       Should applicants pay fees for evaluation of proposed new services even if  no Technical Panel is needed?  Why is this being changed from the process followed in the 2012 round?

There were actually two different panels in 2012:
- Registry Services Evaluation Panel (which shouldn't be confused with Registry Services Evaluation Procedure, or RSEP), performed by an ICANN contractor
- Registry Services Technical Evaluation Panel (RSTEP), performed by technical experts from the community (https://www.icann.org/resources/pages/technical-evaluation-panel-2012-02-25-en)

All applications were evaluated by the former, and the cost of that was included in the 185,000 application fee. Besides issuing CQs or failing applications, the evaluators could have referred the application to an RSTEP, which if called upon, would have cost an extra fee, estimated by AGB at 50,000.

Nothing is being changed about RSTEP, but instead of the evaluation panel, applicant would have the option of checking a box saying "only pre approved services" and avoiding that evaluation altogether. And if that evaluation was requested by applicant, that would be done by same ICANN Org staff that currently does RSEP for the already contracted registries. The reason for a possible fee, which I will remind again is off-topic for WT4 recommendations but we can discuss the theme, is that RSEP costs are currently carried out by the quarterly registry fee, and in this case applicants wouldn't still be paying ICANN fees, so it wouldn't be unreasonable for ICANN to charge a fee. But if WT1 prefers recommending ICANN not to charge fees in order to foster innovation, that would be fine too; both are reasoned policy decisions.

Rubens

________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170905/d903a145/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6500 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170905/d903a145/image002-0001.png>