[Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017

Wed Oct 11 19:09:22 UTC 2017

Rubens,
Are you saying that staff recommended stick with current policy and current AGB language in Question 23 as an alternative?
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:image003.png at 01D34289.C53230F0]

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, October 10, 2017 5:43 PM
To: Aikman-Scalese, Anne
Cc: Julie Hedlund; gnso-newgtld-wg-wt4 at icann.org
Subject: Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 October 2017

On Oct 10, 2017, at 6:31 PM, Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>> wrote:

Dear all,

Cheryl has asked that we consider an be prepared to discuss Slides 12, 13, and 14 in the attachment in our October 12 call – three Straw Proposals re new registry services in applications.

After our call, Policy staff suggested to WT4 leadership, and it was promptly accepted, to also list current policy and implementation(p+i) as another proposal. They also called our attention to the fact that SP2 is that looks more closely to current p+i, but that all 3 proposals look more similar among themselves at to current p+i than dissimilar.

</co-chair>

 Regarding the three Straw Proposals as to whether or not a registry operator needs to describe new services in its application, one item we have not fully considered is that the GAC is still likely to have input at the application stage.  If the GAC has input, I don’t think we want to foreclose the GNSO or other policy (e.g. ALAC) input to the Board.

There is a public comment period for all applications that allow any stakeholder, organised or not in an SO or AC, to provide input on applications.

There is also the Objection process to be considered and new registry services could be relevant to evaluating an Objection.  (This is also why the Answer to Question 18 – purpose of the TLD is relevant.)

If an applicant wants to settle a dispute with an objector, it can file a change request and add such registry service if that helps bring peace among the parties...

One risk we face in Straw Proposals 1 and 3 (by not requiring new services to be listed in an application) is that the Community (including the GAC)  may want more involvement in the RSEP process.  For example, if no disclosure of new services is required in the application, should a public comment period for new services proposed via RSEP be mandatory?   (This is a transparency issue.)

That's a policy outside of the scope of this PDP.

The RSEP process is detailed at the link below.  It says that the new service may or may not call for public comment if it “sets new precedent or has substantial effect on ICANN, third parties, or the DNS.”  So at present ICANN org  determines this I guess.  To my mind there is a question whether a change in the application process that does not require a description of new services would necessarily implicate a reexamination of the RSEP process detailed here:

https://www.icann.org/resources/pages/workflow-2012-02-25-en

The current RSEP implementation is known to be wrong and to have deviated from GNSO and Board approved policy. This is currently under efforts to rectified; that said, what was done in 2012 on what is still suggested by all proposals is to follow then-applicable RSEP implementation for evaluating such services, which aside scalability gains, also provider fairness among applicants and incumbent registries.

There is a comparison statement on Slide 15 which points out that Straw Proposal 2 requires all services to be described in the application.  However, the second part of Straw Proposal 2, establishment of a “fast-track” for pre-approved services definitely contemplated that pre-approved services can be named and that would certainly allow for a friendly amendment to Straw Proposal 2 to state that all new services should be detailed but that pre-approved services can just be listed.

Sounds reasonable to me.

So it seems that #1 and # 3 don’t require any listing of pre-approved services or new services.   This would leave any new services to the RSEP process and leave pre-approved services undisclosed in the application.    But the RSEP process doesn’t require public comment if ICANN org determines that is not needed.

And ICANN Org can only request public comments if a service is found to be a possible security or stability risk. And in that case, there are actually two public comments: one when the matter is referred to RSTEP, for the panel to address both their views on the proposed service and concerns raised by the community, and one when the RSTEP findings are sent to the Board. So a properly-administered RSEP process following GNSO/Board policy either have 0 public comments or two public comments.

Straw Proposal  # 2 requires listing of new services and assessment of any security/stability concerns, but could either specify (a) no listing of pre-approved services or a (b) simple listing of said pre-approved services (to be determined)  without a lot of detail.

Which I believe goes to the other suggestion made before.

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/20171011/3836de98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 6488 bytes
Desc: image003.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171011/3836de98/image003-0001.png>