[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 13 March 2019

[Kathy Kleiman]

Hi Jeff and Cheryl,

Per your invitation, I share my recollections of the Kobe meeting below 
(which are different) and the uncertainty I share with Anne and others 
about the consensus call. I think all pigs are equal, but some are more 
equal than others. Let me try to explain:

There was a slide shown in the last face-to-face discussed that 
summarized the subteam discussion of copying certain fields from one 
application as supporting "identical" applications. I raised a question 
about identical applications as something we had never discussed.

- Cheryl, who was sitting right next to me, said that the slide was not 
accurate on this point, and should not be taken too literally. I think 
she said this to the full group as well. [1]

- Krista, who headed the subteam, described her recollection of the 
comments as discussing certain fields for duplication, but not identical 
applications. [2]

- I said I remembered opposition  in the comments to the copying of 
certain fields by IPC. I added that NCSG -- throughout its comments to 
the WG - supported policies that aid the community's ability to review, 
understand and comment on applications. Based on this prior stance, NCSG 
joined IPC in opposing the duplication of certain fields, especially 
those that the community relies on to be distinct and individualized. [3]

To your question, I don't see is [1], [2] and [3] above in your summary 
below.

So a few procedural questions:

A. What's the reason for the WG discussion: Are we only looking at WG 
comments?  Do we care what WG members say?  If many comments come from 
one set of stakeholders, are the others "outvoted"?

B. Can we all get clear and easy access to a few points that will be 
covered before each WG meeting -- with clear links to the underlying 
comment material?  So that we can all easily review the comments and 
background before we enter the discussion - and not have to rely on what 
we remember from eight months ago?

C. Given the importance in the first round (2012) to public portions of 
the application that the community, public and GAC could (and did) 
closely evaluate, and given the clear and high value today that that 
those who will be reviewing the future applications ascribe to them, 
shouldn't our next step as a WG be /strengthening the requirements /for 
clear and distinct responses to certain application fields so the 
community can fulfill its oversight function --/creating a race to the 
top, not a race to the bottom./

Best, Kathy/
/

On 3/19/2019 5:16 PM, Jeff Neuman wrote:
>
> Anne,
>
> Thanks for your e-mails and sorry it has taken a couple of days for me 
> to get back to this and recover enough to respond.
>
> First, I don’t think we should get hung up on the terminology we used 
> for purposes of the triage exercise.  At this point, it does not 
> matter whether something is classified as a new idea or not.  What is 
> important is whether the idea has enough support within the working 
> group to merit further consideration and ultimately whether it would 
> rise to the level of having Consensus support.  So I would strongly 
> encourage us to not dwell on the label that was used.
>
> With respect to the conversation on whether an applicant can elect to 
> copy one application for a TLD (or certain fields from one 
> application) into another application for a second TLD, or whether an 
> applicant can provide one response to a clarifying question and ask 
> that that response be applied to all of its similarly situated 
> applications, is by no means complete at this point.  That said, I am 
> still scratching my head (and this may be just me) to understand (a) 
> what we are trying to prevent / protect against, (b) how the solution 
> of not allowing copying of one answer to put into another application 
> would achieve (a) above, and (c) why is this a concern for us.
>
> What I heard during the discussion (and correct me if I am wrong) was 
> that we wanted to make sure that at least with respect to the 
> description of the mission / purpose or each TLD, there was a concern 
> that by having an option to copy another application, we were 
> encouraging applicants to not differentiate their TLD applications.  
> So perhaps the argument for (a) above is that we are trying to prevent 
> an applicant from submitting identical applications (albeit for 
> separate strings).  But where I get confused is that the solution of 
> not having an option for the system to copy an answer, we are /not 
> preventing copying from going on./  All we are doing is making 
> applicants do this manually (which we cannot prevent)?
>
> And I am also trying to understand the (c), _why are we concerned_.  
> The BC stated in their comments that they thought copying from one 
> response to another “can result in unknown mistakes and may increase 
> chances of errors in the application.”  My confusion is that if we 
> force applicants to “copy” answers manually where identical answers 
> make sense, then that could increase the chances for mistakes over 
> having the system do this in an automated fashion.  And I still don’t 
> understand why we should be concerned if there are similar answers.  
> Leaving out Question 18 (mission/purpose) for the moment, why do we 
> care if the following sections of each application are identical 
> except for having different strings:
>
>   * Applicant Information (Name, Address, Phone Number, Fax, E-mail,
>     Website, etc.)
>   * Primary Contact for the application (Name, DOB, contact
>     information, etc.)
>   * Proof of Legal Establishment
>   * Applicant Background (Directors, Officers, Major Shareholders,
>     Criminal & Cybersquatting History, etc.)
>   * Registry Services (Question 23)
>   * Technical and Operational Capabilities (Question 24 - 29)
>   * Security (Question 30)
>   * Technical Architecture, Database Capabilities, diversity of
>     hardware, software, suppliers, etc.
>   * DNS Services, Data Escrow, Registry Continuity, Failover Testing,
>     Escalation Processes, DNSSEC
>   * Financial Information, Statements, etc.
>
> Even if the mission/purpose of each TLD is different, the reality is 
> that all of the above information is most likely going to be 
> identical.  So, either they will copy each of the answers manually 
> (which is more prone to mistakes) or there can be an automated option 
> to allow the automatic population of these fields which could actually 
> reduce mistakes.
>
> As Chair, for the record, this concept was supported by the Work Track 
> that made this recommendation without any dissent prior to the Initial 
> Report.  As far as the comments we got back, ICANN agreed with the 
> recommendation, but expressed concern as to the complexity of 
> implementing this. The only comment that disagreed was from the BC.  
> Neustar, Lemarit, Fairwinds and the BRG supported the recommendation.
>
> This e-mail does not represent any form of decision or guidance by the 
> Co-Chairs of the SubPro PDP, but is merely intended to provide some of 
> my outstanding questions on the concerns.  Thanks.
>
> *Jeff Neuman*
>
> Senior Vice President
>
> **
>
> *Com Laude | Valideus
> *1751 Pinnacle Drive
>
> Suite 600, McLean
>
> VA 22102, USA
>
>
> M: +1.202.549.5079
>
> D: +1.703.635.7514
>
> E: _jeff.neuman at comlaude.com_
> www.comlaude.com <http://www.comlaude.com/>__
>
>
> Liability cannot be accepted for statements made which are clearly the 
> sender’s own and not made on behalf of Com Laude USA or Valideus USA. 
> This message is intended solely for the addressee and may contain 
> confidential information. If you have received this message in error, 
> please send it back to us, and immediately and permanently delete it. 
> Do not use, copy or disclose the information contained in this message 
> or in any attachment.Com Laude USA and Valideus are trading names of 
> Consonum, Inc.__
>
> *From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> *On Behalf 
> Of *Aikman-Scalese, Anne
> *Sent:* Wednesday, March 13, 2019 4:47 PM
> *To:* Julie Hedlund <julie.hedlund at icann.org>; gnso-newgtld-wg at icann.org
> *Subject:* Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD 
> Subsequent Procedures PDP WG - 13 March 2019
>
> Thanks Julie. To Jeff and Cheryl, I don’t think the concerns raised by 
> Kathy, Justine, and me in the Sub Pro call #3 about “rote duplicative 
> answers” as to Question 18 constitute a “new idea”. These were rather 
> concerns expressed about moving forward with a policy recommendation 
> to change the existing policy in the 2012 AGB.   Requiring individual 
> answers in Question 18 is not a “new idea”.  It’s existing policy 
> which should not be changed unless there is a strong consensus in the 
> WG in favor of doing so.
>
> Based on what I have gleaned from our structure so far, it appears 
> that Leadership could take the position that a “new idea” may only be 
> recommended if it has unanimous or very strong support.  (This doesn’t 
> mean the WG won’t reach Consensus as to repetitive information being 
> filed in numerous applications at the same time in categories other 
> than mission and purpose.)  But the fact that this idea received 
> support in public comment should not override concerns of Working 
> Group members relative to transparency and encouraging practices which 
> facilitate public comment.  So, in fact, rather than being a “new 
> idea’, what you have is a lack of strong Consensus in the WG about 
> this recommendation for the auto-fill capability as it relates to 
> questions dealing with mission and purpose.  Again, that is NOT a 
> policy change or a “new idea.”
>
> This will come up again in relation to the disclosure of services at 
> the time of application filing.  So it would be good if Leadership 
> could clarify EXACTLY how it intends to treat items that are 
> characterized as a “New Idea.”  Call me crazy but I think everyone is 
> still a bit confused as to the “disposition” going forward in relation 
> to “new ideas”.
>
> Thanks again for your willingness to bring this PDP “home”.  It’s not 
> an easy job and we really do appreciate Cheryl’s comment that “they 
> said it couldn’t be done” but the work is getting done.  My only point 
> is that characterizing something as a “new idea” in relation to the 
> questions that were put out in the Initial Report should not be used 
> as a way to cast aside an obvious lack of Consensus in the WG on a 
> given recommendation.    The WG will have to be careful about this all 
> the way through its deliberations in the coming months.
>
> Safe return travels to all.  I could not make it to Kobe but am 
> planning to be in Marrakech and Montreal.
>
> Anne
>
> *From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] *On 
> Behalf Of *Julie Hedlund
> *Sent:* Wednesday, March 13, 2019 1:19 AM
> *To:* gnso-newgtld-wg at icann.org <mailto:gnso-newgtld-wg at icann.org>
> *Subject:* [Gnso-newgtld-wg] Notes and Action Items - New gTLD 
> Subsequent Procedures PDP WG - 13 March 2019
>
> *[EXTERNAL]*
>
> ------------------------------------------------------------------------
>
> Dear Working Group members,
>
> Please see below the notes from the meetings at ICANN64 in Kobe on 13 
> March 2019. These high-level notes are designed to help WG members 
> navigate through the content of the call and are not a substitute for 
> the recording, transcript, or the chat, which will be posted at: 
> https://community.icann.org/display/NGSPP/2019-03-13+ICANN64+Kobe+-+New+gTLD+Subsequent+Procedures+PDP.
>
> Please also see the attached referenced slides.
>
> Kind regards,
>
> Julie
>
> Julie Hedlund, Policy Director
>
> *Notes and Action Items:*
>
> *Session 3 of 3:*
>
> _Topics that Might Warrant Closure_:
>
> -- Show how we have assembled the topic review.
>
> -- How to bring this to closure.
>
> -- Next steps.
>
> -- Still are some potential open topics that might need to go to the 
> Implementation Review Team or do more work.
>
> See the Public Comment Tool: 
> https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit#gid=1093601017
>
> _1. Applicant Guidebook – Slide 20_:
>
> -- Information on the slide is conceptual, not recommendation language.
>
> _2. Systems – Slides 21-22_:
>
> -- Question: Which of the recommendations are implementation guidance 
> and which are policy?  The first bullet (adequate time) would be more 
> specific than policy; second bullet suggests implementation guidance.  
> Also, change to “real-time technical support” (delete “better”).
>
> -- Both bullet points seem to be implementation guidance.
>
> -- Prioritization would be key (such as identifying field requiring 
> non-ASCII characters).
>
> Christopher Wilkinson: <COMMENT>Ihave a general reservation abiout 
> language which woud facilitate multiople applications from a single 
> applicant. Particularly with regard to Geographical Names<COMMENT>
>
> Christopher Wilkinson: <COMMENT> permitting portfolio applications 
> will  result in further concentration, more warehousing and 
> speculation and threaten the interests of international communities 
> <COMMENT>
>
> -- Creating multiple identical applications doesn’t seem to serve the 
> Applicant Guidebook Process. Comment from Business Constituency was to 
> be able to respond to multiple applications with the same question.  
> That this answer applies to multiple applications.
>
> -- Sections in some applications may be pretty much the same, so the 
> ability to copy text over would be beneficial.
>
> -- Should encourage clarity of what is expected in the answers.  Would 
> be helpful to know in advance what is expected of applicants.
>
> Anne Aikman-Scalese (IPC): COMMENT: Answers to Question 18 should not 
> be rote fill-in identical answers. COMMENT
>
> Anne Aikman-Scalese (IPC): COMMENT: +1 to Justine 's request and to 
> Kathy's observation re Question 18. We don't want to encourage super 
> general language that is made more vague so that it can be applied 
> automatically in numerous applications.  COMMENT
>
> -- Should allow copy and pasting the same answer to purpose and 
> mission, but how can we prevent that? Could do so by setting expectations.
>
> -- The discussion was around efficiency and ease of use for 
> applicants.  We didn’t consider what to allow for which questions.
>
> Christopher Wilkinson: <COMMENT> boilerplate replies from multiople 
> applications will facilitate gaming to avoid substantive comments from 
> other stakeholders and interested parties<COMMENT>
>
> Anne Aikman-Scalese (IPC): COMMENT:  Re public comment on 
> applications, cookie cutter answers are contrary to the principle of 
> transparency.  Applicants might easily construct such answers for the 
> purpose of avoiding public comment.  Justine's request is important.  
> COMMENT
>
> -- The more complex we make the system the more costly it will be and 
> difficult to use.
>
> Anne Aikman-Scalese (IPC): COMMENT: It's demeaning to the comments to 
> say they are "in the weeds" and they are not "high level".  it just 
> means you oppose them. COMMENT
>
> -- To address the issue you’d have to have a policy recommendation 
> that you can’t submit the exact same information across applications 
> or within applications.
>
> -- What is the problem we are trying to solve, at a high level?  If 
> you can cut and paste you will do it, but don’t know if that will 
> avoid the issues being raised.
>
> -- Seems that the problem is the pace the submission outpacing the 
> ability of the community to review the volume of applications received.
>
> -- New Idea: Maybe prohibit duplicative language if you are a 
> portfolio applicant.
>
> Anne Aikman-Scalese (IPC): COMMENT:  It is not about solving a 
> problem, it is about creating a new problem by making this 
> recommendation.  Jeff's suggestion to use languge that excepts the 
> practice in relation to questions that go to Mission and Purpose.  
> That is not a policy change. COMMENT
>
> Christopher Wilkinson: <COMMENT> one of the objectives of having 
> several specialised rounds or batches is precisely to limit the 
> volumes of applications to the capacity of the evaluation resources, 
> over time <COMMENT>
>
> _3. Communications – Slides 23-24_:
>
> -- Bullet 1: Minimum of 4 months – shouldn’t be summarized; there was 
> a variety of comments.
>
> -- Bullet 2: Know what is in the GSE toolbox.
>
> -- For the two bullets – not a lot of mention of studying of 
> objectives and holes for applications; what are we looking to achieve 
> by communications and outreach.  Would be good to measure.
>
> -- When we were talking about applicant support there were comments on 
> how to measure success in future.
>
> -- Communications is different from applicant support, but we need to 
> look at both.
>
> -- Open topics:  The WG could do it, give it to an IRT, or recommend 
> that ICANN Org do it.
>
> Christopher Wilkinson: <COMMENT> communications periods will be 
> critical for geographical names because very few of local stakeholders 
> world wide have been participating in Wt5 etc. <COMMENT>
>
> Anne Aikman-Scalese (IPC): QUESTION  Was there something in the public 
> comments related to making real-time chat available for applicants?  
> QUESTION
>
> _4. Universal Acceptance – Slide 25_:
>
> -- UASG has been successful in promoting UA – getting several major 
> email providers to be UA ready.  The question is whether the 
> Registries/Registrars are using those email services.
>
> -- Might be too much to ask to expect Registries/Registrars to do what 
> the major email providers do.
>
> -- This sounds like more of an issue with all TLDs – why would we just 
> put it in as a condition of a new TLD if it isn’t a condition for 
> legacy TLDs?
>
> -- ALAC – suggesting UA if the Registry/Registrar are owned by the 
> same entity.
>
> _5. Application Submission Periods – Slides 26-27_: Start on the next 
> WG call.
>
> Anne Aikman-Scalese (IPC): COMMENT: Re Topic 5, how do we take into 
> account the Neustar proposal re windows within an application period?  
> That should be captured.  COMMENT
>
> ------------------------------------------------------------------------
>
>
> 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.
>
>
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190320/521f59a7/attachment-0001.html>