[Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - 29 May 2018 at 20:00 UTC

[Rubens Kuhl]

Anne,

Responses inline.


> Em 30 de mai de 2018, à(s) 15:23:000, Aikman-Scalese, Anne <AAikman at lrrc.com> escreveu:
> 
> Rubens,
> 
> As noted, the discussion on this issue in Work Track 4 was lively.  Should applicants be required to describe all new services intended to be offered in their applications as per existing Question 23 or not?  Clearly this would be required if closed (exclusive) generics are permitted – in order to evaluate whether those applications serve a public interest.

There is no connection between the WT4 discussion and the closed generics one. If something appears in the public comment for the initial report, the WG will be able to see if there is some unintended effect of the policy when looked in tandem.

> There is also a question about whether the public should know what services are being proposed in connection with each new gTLD.  Admittedly there are trade-offs here.  It strikes me that given the delays in the 2012 round, the Contracted Parties would be interested in aggregated technical and financial evaluation and pre-approved services in order to get under contract quickly and be able to launch.  This is because “time is money”.


This is not what was decided in the consolidated model. Even the pre-approved services will have to be declared by the applicant.


> They would then follow the RSEP process to add services, which is a process that occurs as a negotiation between the registry and ICANN only.  The trade-off is that the true purpose of the TLD may not be disclosed at a time when the public is paying attention.


This is already true for the 2012-round. Every applicant that preferred not disclosing such intention could have proposed only the minimum required services.

> 
> For example, can RSEP be used to request a waiver for a dotless Top Level Domain?

No, but the reason for that is that the RSEP would be sent to an RSTEP panel, and an RSTEP panel can't issue such a waiver today considering the IAB guidance on it.

> Members of the community will watch and analyze new gTLD applications.  They don’t necessarily “watch” RSEP requests.

That's up to the community. RSEP requests are as public as any other activity in the ICANN world. Perhaps we could count on you to publicize that more ?

> 
> The Subsequent Procedures PDP runs on the principle that if the PDP recommendation does not change existing policy, the policy remains the same.  In this case, it has not been clearly pointed out that not requiring disclosure of new services at the time of application (if they are actually intended at that  time) is a CHANGE in policy when viewed in light of existing Question 23.  Again, this was discussed at length in Work Track 4.

The PDP also runs on the GNSO procedures that don't require unanimity to establish consensus.

> 
> The fact is that in Work Track 4 discussions, there was support for each of the three proposed models:  one proposed by you, one proposed by me, and one proposed by Kurt Pritz.   In all three models, there was agreement on development of a list of pre-approved services, but there was in fact no agreement on eliminating the part of Question 23 that requires disclosure of all new services at the time of application.   (We cannot get around this fact by stating – hey, don’t worry, there was no consensus call – because we are indeed treating the Initial Report as if there had been agreement on recommendations within the Work Track itself.)

In this case, there was in fact an agreement to require the list of services from applicants, doesn't matter where they are pre-approved or not. What was added different from 2012 was the ability for applicants to disclose services that wouldn't be evaluated at application time, making their intentions more transparent, not less transparent.

> 
> Regarding San Juan,  I do not know who arrived at the “one model”.    I was in the session remotely, but had been assured repeatedly that there would be future discussion of the three models.

It was your choice to not weigh in regarding the model. That was the opportunity to do so, because that was the discussion of the registry services theme.

> As you and Jeff and Cheryl know very well, I expressed concern that such discussion should occur before the draft Initial Report was prepared.   Jeff responded on February 28 that the comments would be captured and that staff was tracking all the correspondence.   Jeff kept saying, “let’s just see what the draft Initial Report says when it comes out.”   So now  here we are.   (The November 30 calls and the follow-up e-mails in January and February as well as questions about this in subsequent calls are on record.)
> 
> All the draft Initial Report says is There was support for continuing to allow applicants to submit new registry services at application submission, or after delegation, as is the case currently, though some sought to make the declaration  of registry services compulsory at application submission.”   This sentence is drafted as if requiring a description of new services at the time of application would be a change in policy, while the opposite is true.

It would be a change in the RSEP policy if any possible future service would have to be declared at application time.

> It is also misleading in its use of the phrase “as is the case currently”.  That applies currently to RSEP requests, but is not the case currently as to descriptions of services required at the time of application.  Once again, below is the text of Question 23 as it now stands.  This time I highlight the relevant policy in red lettering in order to emphasize the point that the AGB  language change proposed (and characterized as being proposed by Work Track 4) is a CHANGE in policy.
> 
> 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.
> 
> 
> Certainly it is not accurate that Work Track 4 agreed on eliminating the requirement to disclose “all services” proposed to be rendered in accordance with existing Question 23.

As I said, the requirement was kept.

> I also think that regarding “Deliberations” and “how this was handled in the 2012 round”, we need to clearly state what Question 23 said when this type of change is being proposed.   (This is reflected in the redline previously forwarded to the list and forwarded again here – with redline changes beginning on page 36.)
> 
> The issue presented was the subject of much discussion and was documented via numerous e-mails and comments in Work Track 4.  The draft Initial Report does not accurately reflect this discussion.  Hopefully Leadership will be ready to correct this in the interest of transparency and for the purpose of collecting genuine and informed public comment.

Providing the specific redlines asked for previously would assure that they can be incorporated. Providing a boat-load of redlines to other things doesn't assure that, although not preventing staff from extracting those specific requests and incorporating them anyways.



Rubens





> Anne
> 
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 office
> 520.879.4725 fax
> AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> _____________________________
> <image003.png>
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 2000
> Tucson, Arizona 85701-1611
> lrrc.com <http://lrrc.com/>
> 
> 
> From: Rubens Kuhl [mailto:rubensk at nic.br <mailto:rubensk at nic.br>]
> Sent: Tuesday, May 29, 2018 5:59 PM
> To: Aikman-Scalese, Anne
> Cc: Steve Chan; gnso-newgtld-wg at icann.org <mailto:gnso-newgtld-wg at icann.org>
> Subject: Re: [Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - 29 May 2018 at 20:00 UTC
> Importance: High
> 
> 
> 
> Thus, the Initial Report should be revised to  accurately reflect the discussion in Work Track 4.  Various other points relevant points are raised in the attached redline beginning on page 36 and continuing to the end of Section 1.7
> 
> 
> Anne,
> 
> Your recollection doesn't seem to include the face-to-face session in San Juan, when the topic of registry services was discussed and a replacement model has been introduced. You can see the transcript here, starting page 19:
> https://static.ptbl.co/static/attachments/169219/1520870375.pdf?1520870375 <https://static.ptbl.co/static/attachments/169219/1520870375.pdf?1520870375>
> 
> The Adobe Connect recording is still unavailable, but the audio starts at 41:00 into the recording:
> http://audio.icann.org/meetings/sju61/sju61-OPEN-2018-03-10-T1620-104abc-TonbGmBb9uRYShJQTxpe8XrjBqOkOJKI-en.m3u <http://audio.icann.org/meetings/sju61/sju61-OPEN-2018-03-10-T1620-104abc-TonbGmBb9uRYShJQTxpe8XrjBqOkOJKI-en.m3u>
> 
> I don't remember any interventions from you during the session.
> 
> 
> 
> 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.
> <Section 1.7 Application Evaluation_Criteria_4May2018 - AEAS redline 28 M....docx>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180530/8977a06f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180530/8977a06f/signature-0001.asc>