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

Jeff Neuman jeff.neuman at comlaude.com
Wed Mar 20 19:12:34 UTC 2019


Thank you Kathy.  Please find my comments below in Red. Sorry this is long, but I felt your comments merited a comprehensive response.  This response is my response and I am sure Cheryl has her own thoughts which may be different from mine.

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of Kathy Kleiman
Sent: Wednesday, March 20, 2019 12:17 PM
To: gnso-newgtld-wg at icann.org
Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 13 March 2019


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.

[Jeff] As was explained a number of times during the meeting, we truncated subjects on the slides so that they could fit on a slide.  This meant that summary terms were used when they may not have been the right terms.  By identical applications, we were referring to Applications by a single entity for which the only material difference was the actual string.  But the label identical is not important for the concept.  The question is whether the system should contain an option to allow an Applicant that files multiple applications to copy some/all of the fields from one application into another application where the answers will be the same regardless of the string.  Please focus on the concept and NOT on the label used in the slide.  Slides are a tool to aid in discussion and nothing more.

- 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]

[Jeff] See comment above.

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

[Jeff] See comment above.

- 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]

[Jeff] I went back to the comments to do some research and it was NOT the IPC that filed comments on this subject, but rather it was the Business Constituency as I explained below.  With respect to the NCSG comment, no where in the filed comment does it state the stance you have taken (namely opposing the duplication of fields).  See https://mm.icann.org/pipermail/comments-gtld-subsequent-procedures-initial-03jul18/attachments/20180928/257c446e/InitialReportontheNewgTLDSubsequentProceduresPolicyDevelopmentProcess-NCSGcomment-0001.pdf.  Not to diminish your comment at all, we cannot extrapolate that the opposition of duplication of certain fields is at this point an NCSG position.  Of course an official statement from the NCSG could always amend that.

[Jeff]  Now, to the point of my comment below.  Yes the NCSG did comment on its ability to review and comment on applications.  But you have made an assumption in your last sentence that the community relies on applications to be “distinct and individualized.”  Again, this is a comment you made, but one that has never been made before.  Please explain from what source did you rely on for that assumption.  And then please explain the link between whether the system allows the copying of certain fields from one application to another and interfering with “the community’s ability to review, understand and comment on applications.”

Also, lets be clear on which fields you are referring to.  Are the bulleted fields the ones you are concerned about, or as we discussed, is it really any questions dealing with mission, purpose, registration requirements, etc.

We could for example allow the copying of all fields other than those dealing with the mission, purpose, registration requirements, etc.  That would be a middle ground and one that would facilitate consensus especially when there are a number of people, groups, etc. that have commented in support of allowing copying.  Help us get to consensus.

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"?

[Jeff] The point now is not to completely rehash every single discussion from scratch.  After all we have had 3 years of discussions on topics.  So, yes we are looking at WG comments AND we care about WG members say.  But we ask that the Working Group work towards figuring out ways to integrate their own subjective views with the recommendations from the Initial Report (where there were such recommendations) and the multiple comments that we have received during Community Comment 1, Community Comment 2, the Initial Report Comments Period and the Supplemental Initial Report Comment Period.  To the extent that a Working Group Member just starts to become involved in the process and tries to rehash the same discussions that have already taken place and which are not supported by the comments that we have received or the Initial Report, then the Co-Chairs may cut off those discussions.

[Jeff] On your question on being outvoted, the answer is obviously no.  We do not vote.

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?

[Jeff] Everything is posted on our wiki including the calendar of discussions as well as clear links to the comments.  It is all there and has always been there.  We expect that everyone that attends the calls have done their homework and has read what they need to have read to be prepared.  For example, Julie Hedlund posted the Agenda for the meeting March 25th as well as the links to the documentation.  She sent this out to the group on March 14th.

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.

[Jeff]  I would ask that you please refrain from platitudes like “creating a race to the bottom” as this negatively implies that the leadership of this WG and the rest of the Working Group are not taking their roles seriously.   It also implies that those who may not agree with your views are trying to make the process worse or that the substance of their views are inferior to your own.  I know that that is not the intent of your message, but I always try to assume that every member of the Working Group is doing their best to improve the program.  For example, taking this e-mail as a whole, the message I am getting is that if we ask for a system that allows some fields to be copied from one application to another (if submitted by the same applicant), then that will in some way adversely impact the public’s ability to review, evaluate and comment on applications.  And that in turn will create a race to the bottom.  We need to ask the Working Group members whether they share that view as well.

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<mailto: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><mailto: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><mailto:julie.hedlund at icann.org>; gnso-newgtld-wg at icann.org<mailto: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<mailto: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/9cfa233b/attachment-0001.html>


More information about the Gnso-newgtld-wg mailing list