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

[Rubens Kuhl]

> On Oct 10, 2017, at 6:31 PM, Aikman-Scalese, Anne <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171010/bd3f3f93/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171010/bd3f3f93/signature.asc>