[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC

Martin Sutton martin at brandregistrygroup.org
Sun Feb 9 07:55:20 UTC 2020


Thanks for raising this Donna, there is a big difference between a few people being heard vs the group agreeing to adopt what they say.

Jeff, thanks for the detailed listing of outcomes which makes it suitably clear and puts the issue into perspective (as was also attempted on the call by others). Keeping it simple, your text could be lifted and used as implementation guidance, supporting the policy that no applications can be accepted for previously applied strings that are delegated or in process.

Kind regards,

Martin

Sent from my iPhone

On 9 Feb 2020, at 00:56, Austin, Donna via Gnso-newgtld-wg <gnso-newgtld-wg at icann.org> wrote:


Regardless of whether this is a policy or implementation issue, I just want to note that there were 20+ people on the call and I’d like to understand how we’re taking into account the views of others that had expressed a different opinion to Greg, Anne, Justine and Kathy who came in very very late in the call about the substance of the issue.

Donna

From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] On Behalf Of Greg Shatan
Sent: Friday, February 07, 2020 12:55 PM
To: Alexander Schubert <alexander at schubert.berlin>
Cc: gnso-newgtld-wg at icann.org
Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC

Jeff,

I said on the call that this issue is policy.  The call transcript is not available yet, but  this is in the chat transcript, responding to me:

01:26:52               Justine Chew:    +1 Greg on this being a policy issue not IG
01:27:56               Anne Aikman-Scalese:   +1 to Greg and Justine - this is a policy issue and it will likely apply in the future to strings we are not even considering at this point.

The discussion went on from there, both in the chat transcript (attached) and on the call.  The
chat transcript mentions "policy" 21 times.
There's no definitive test for "policy vs. implementation." All attempts to create one have failed AFAIK.  However, one informal "barometer" I use on "policy vs. implementation" is what I call the "WTF Test."  If you look at a policy, and the intention is clear and there would be little disagreement about what the implementation would look like (regardless of your "position"), you're good. Anything more detailed tends to be implementation.
But, if you look at a policy and say "WTF" (e.g., "WTF were they thinking?", "WTF did they mean by that?", "WTF are we supposed to do with this?") then there's still policy work to be done.
In this case, there's still policy work to be done.  The range of outcomes discussed were broad and contradictory and the dividing lines that produced one result over another were unclear. There's no clear existing policy or policy recommendation to guide the group, or the implementation team.
We need to come out of this with a clear rule about what to do with new applications for strings where there are prior round applications for the same string (or possibly, an overly "similar" string) with these two statuses:
·        Not Approved – The application is not approved and shall not continue in the New gTLD Program as a result of a resolution passed by the ICANN Board of Directors or a Committee of the ICANN Board, such as the New gTLD Program Committee.
·        Will Not Proceed – The application has completed a Program process, and based on the outcome will not continue, as defined in the AGB. This could include process outcomes including but not limited to not passing evaluation, not prevailing a dispute resolution proceeding, not prevailing in contention resolution.
Alexander's suggestion makes sense, though I would extend it to both categories above.  Perhaps terminated applicants could get a discount if they reapply for the same string.

Best regards,

Greg




On Fri, Feb 7, 2020 at 2:57 PM Alexander Schubert <alexander at schubert.berlin<mailto:alexander at schubert.berlin>> wrote:
Suggestion:

•        If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).

Thanks,



Alexander.berlin





From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org<mailto:gnso-newgtld-wg-bounces at icann.org>] On Behalf Of Aikman-Scalese, Anne
Sent: Freitag, 7. Februar 2020 14:00
To: Jeff Neuman <jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>>; 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 - 06 February 2000 UTC

Thanks Jeff.  I think the degree of discussion on the call confirms that the issue is not about “every little detail”.  It’s a “high level” policy issue.

PROBLEM WE NEED TO SOLVE:  As I see it, the biggest problem with the first option is that a prior applicant could effectively block new applicants for a string forever by refusing to withdraw an application that is “Not Approved” for policy reasons and by refusing to adopt the new policy.  This is not limited to applications from 2012, it’s about policy going forward and relates to applications we have not yet seen.   The issues involved could extend well beyond name collisions in to areas no one has yet anticipated.

PROPOSED COMPROMISE LANGUAGE:  Pursuant to your request, I have entered language with a proposed compromise that would accept the first Option but with the caveat that the applicant(s) from the prior round would confirm in writing to the Global Domains Division that they are willing to comply with new policy and the new AGB and that they do so prior to the opening of the window for the next round.  If they are unwilling to do so, then new applicants should be permitted to apply for the string in a “back-up offer” position.

Anne

From: Jeff Neuman <jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>>
Sent: Friday, February 7, 2020 11:49 AM
To: Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>>; 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: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC

[EXTERNAL]
________________________________
Ok, I tried to clarify because I think I may have said something that inadvertently triggered the policy vs. implementation discussion.  What I said was something to the effect of “We could say that the policy is that we will not accept any applications for a string that was applied for in the past round so long as that application was still being processed.”  And then I followed that up with something like “and we can leave it to the Implementation team to define what it means to still “be in process”.

I must not have communicated that as well as I should have because that is when people started saying that this issue was policy as opposed to implementation (Which was not the point of what I was trying to make).

SO, bottom line, no one said on the call, nor am I aware of anyone that believes, that this issue in general is “policy.”  However, if we cannot agree on every little detail, then we can leave some of those details to the Implementation Review Team.

I hope that helps.

Jeff Neuman
Senior Vice President
Com Laude | Valideus
D: +1.703.635.7514
E: jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>

From: Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>>
Sent: Friday, February 7, 2020 1:32 PM
To: Jeff Neuman <jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>>; 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: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC

I am just noting that at least three active participants said the whatever we ultimately conclude on this point is policy.    I think Greg raised this, with Justine saying +1 and I agreed it’s Policy and then Kathy K. chimed in.

In our report, we have  the categories you describe.  I know Karen said that Implementation Guidance carries strong weight, but it seemed that the point being made was that the issue was a Policy issue rather than Implementation issue.    The distinction likely becomes important for the IRT.

Thank you for asking.
Anne



From: Jeff Neuman <jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>>
Sent: Friday, February 7, 2020 9:47 AM
To: Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>>; 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: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC

[EXTERNAL]
________________________________
Just to clarify Anne, are you saying that the proposal to ban new applications for string not yet withdrawn should be labeled as a “recommendation” and opposed to “Implementation Guidance?”

If it something different, than please explain.

Jeff Neuman
Senior Vice President
Com Laude | Valideus
D: +1.703.635.7514
E: jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>

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: Thursday, February 6, 2020 5:42 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 - 06 February 2000 UTC

Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”?
Anne

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org<mailto:gnso-newgtld-wg-bounces at icann.org>> On Behalf Of Julie Hedlund
Sent: Thursday, February 6, 2020 3:02 PM
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 - 06 February 2000 UTC

[EXTERNAL]
________________________________
Dear Working Group members,

Please see below the notes from the meeting on 06 February 2000 UTC. 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/2020-02-06+New+gTLD+Subsequent+Procedures+PDP<https://urldefense.com/v3/__https:/community.icann.org/display/NGSPP/2020-02-06*New*gTLD*Subsequent*Procedures*PDP__;KysrKys!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgsleKdHoc0$>.

Kind regards,
Julie

Notes and Action Items:

Actions:

Work Plan:
ACTION ITEM: Staff will send a link to the revised work plan/timeline.

2.2.1 Continuing Subsequent Procedures
ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation.  Note also the sources of metrics in the footnote.

ACTION ITEM: Change text as follows: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.”

Notes:

1. Updates to Statements of Interest:

-- Avri Doria will be participating as one of the Board Liaisons to the WG.  The other Board Liaison is Becky Burr.
-- Question: What does that mean in terms of the role of the Board Liaison?  Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers.
-- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do.

2. Work Plan

-- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work.
-- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met.  As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request.
-- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February.
-- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this.
-- New work plan shows the schedule of meetings to cover all of the topics.
-- Unless the WG can work faster it would be delivering a Final Report by the end of 2020.
-- This is just a preview; a link will be sent later.
-- This is assuming a two meetings per week schedule.
-- Some of these topics may not take two full meetings, but we’ve built that in as a buffer.
-- Some things we could do to streamline this.  One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings.  Such as two 3-hour sessions in April and May we could save a month or more.
-- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions.
-- Goal is to get the revised work plan and Project Change Request to the Council by early next week.
-- Agree that we would need to schedule longer sessions well in advance, say two months.
ACTION ITEM: Staff will send a link to the revised work plan/timeline.

3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing<https://urldefense.com/v3/__https:/docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgsleDAw8U2$>.

Structure:
-- Affirmations are confirming the 2012 policy/AGB.
-- Recommendations are things that must happen.
-- Implementation Guidance are things that should happen.

a. 2.2.1 Continuing Subsequent Procedures

Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained.

Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.”

Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS.

Recommendation xx (see rationale 3).  Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared.

Discussion:
-- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data?  There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance.  Not trying to override ICANN Org’s plans.
-- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report.  Don’t see how these can be collected.
-- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations.
-- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time.  Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details.  We wanted to leave it to implementation as to what types of data would be collected and how.
-- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance.
ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation.  Note also the sources of metrics in the footnote.

b. 2.2.3 Applications Assessed in Rounds

Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.”

Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process.

Implementation Guidance  xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed.

Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition.

Discussion:
-- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch?  Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round?
-- In Implementation Guidance we suggested two options since comments were widely varied.
-- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time.
-- The second option gets pretty complicated when you are trying to determine contention sets.  Not sure how you would do it.
-- This is not meant to allow someone to get into an already existing contention set.  In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round.
-- Recommendation: preference is that ICANN publish a date.

-- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity.
-- Disagree that strings from last round should be prohibited.  Second option supports the notion of Applicant freedom of expression.
-- From a process perspective the above comment would add complications that really aren't warranted.
-- No evaluation of the new applicant would occur until the 2012 applications are resolved.  The new applicants would have to accept that risk.
-- Concerns about treating moribund applications made a decade ago as reservations for the next round.  Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold?
-- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside.  Then it opens up again for all.
-- Because the window for application is closed  at that point and we haven't said that a new window could open if they all fail.
-- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round.
-- That's one of our recommendations that there will be a series of windows.
-- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”?
-- Favor the second option.
-- Can't live with prohibiting applications for the same string.  If "shall not proceed" means new applicants can still apply, I can live with that.
-- What about applications that have not progressed on purpose?  Or for technical reasons?
-- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process.  If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for.
-- We don’t have a system in place that allows for continuing application periods, we have rounds.  People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply.
-- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur.  We are trying to get to a steady state process.
-- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round.  Need to define in implementation what “in process” means.
-- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions.
-- Surely, all delegated TLDs or those in process, are off limits.
-- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way.
-- Delegated TLDs are not under discussion.
-- The point here are those that are not “in process”, so we need to define “in process”.
-- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so.  (No stonewalling on new policy recommendations - no blocking based on old policy positions.)

-- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.)
-- Question: What about the status “Not Approved”?  Answer: That only applies when an application has gone through all of the steps.  There will be one or two edge cases.
-- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board.  If there isn’t a new policy they shouldn’t be able to block new applicants.
-- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application.
ACTION ITEM: Change Implementation Guidance to: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.”

Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program.

Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds.

Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board.

Discussion:
-- Look at these recommendations together.
-- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds.
-- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round.
-- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD.  What if one of the applicants for .home has no interest in that?  Their application needs to be dead.
-- Those (.home, .corp, .mail) are not withdrawn even though "not approved".   If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application.
-- Rules should apply in each round to those applicants.
-- If you can’t live with the language please suggest new language.
-- Problem seems to be how to fix the “Not Approved” applications from the previous round.  Board may have to decide how to deal with them.  That is out of scope for this WG.

________________________________

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.
________________________________
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://urldefense.com/v3/__https:/comlaude.com__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslTnh2QSF$>

________________________________

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.
________________________________
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://urldefense.com/v3/__https:/comlaude.com__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslTnh2QSF$>

________________________________

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<https://urldefense.com/v3/__https:/mm.icann.org/mailman/listinfo/gnso-newgtld-wg__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslTa0psJZ$>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslRawcG16$>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!N14HnBHF!s4tj4qIGGIEtRUSiY5ZWvIw3ZZR0JYvJefEekRkbL4V03SkujCraUkAOfPgslUaU6myt$>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________
Gnso-newgtld-wg mailing list
Gnso-newgtld-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200209/0b877b99/attachment-0001.html>


More information about the Gnso-newgtld-wg mailing list