Probably “in addition”.

Thank you,

Anne

 

 

 

Dear Anne, apologies, the email below was sitting unsent. Below is confirmation that your suggestion was integrated, but also a questions/suggestion for your and the WG’s consideration.

 

 

Your suggestion has been added to the working draft, although I wonder if this is more applicable to the section on change requests, where the topic of string changes is talked about more fully? Specifically, it might make sense to add to this block of text in section 1.4.d instead (or in addition?):

 

Implementation Guidance: Some examples to consider in allowing for a new string to be selected include prepending/appending a new element to the original string or selecting a string that is closely related to the class/sector of the original string. ICANN org must perform a re-evaluation of the new applied-for string in all string related evaluation elements (e.g., DNS Stability, String Contention, etc.) and the application for the new string would be subject to string related objections (e.g., String Confusion Objections, Legal Rights Objections, etc.). The applicant may be responsible for additional, material costs incurred by ICANN due to re-evaluation and the application could be subject to delay.

 

Best,

Steve

 

Thanks Steve.  As mentioned on yesterday’s call, I have comments and language for the last bullet point under 1.2 (d).  After considering this language more carefully,  please see the following change in red:

 

• A third option a Working Group Member proposed was allowing certain types of private resolutions, but disallowing others. For example, as discussed in several sections of the Initial Report and in this Supplemental Initial Report, many Working Group members favored allowing applicants in a contention set to change their applied-for-string if that change is mutually agreed by the members of the contention set and the newly changes strings (a) were reasonably related to the original applications and (b) did not move the applicants’ newly selected strings into a different contention set. Under this option, the Working Group member proposed that changes would need to be approved by ICANN.   Another Working Group member noted that under this option, any proposed newly selected string that ICANN intended to approve would need to be (a) subject to name collision risk assessment, (b) put out for public comment and (c) open to established Objection procedures.  If parties are found to have engaged in non-acceptable forms of private resolution, that will result in (a) withdrawing of an application – if an agreement was not signed by the time it is discovered, or (b) forfeiture of the registry (if after a contract is signed). Some members of the Working Group, however, were not comfortable in putting ICANN in a position of approving (or disapproving) mechanisms of private resolution.

 

 

 

 

 

Dear WG Members,

 

Please find the proposed agenda for the New gTLD Subsequent Procedures PDP WG meeting scheduled for 8 October 2018 at 15:00 UTC, for 90 minutes.

 

1. Agenda review/SOIs
2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued
3. Planning for ICANN63
4. AOB

    

For agenda item 2, please find the latest draft, which accepted all red-lined edits made prior to the 2 October meeting (you can find that draft here: https://community.icann.org/x/4QirBQ). As it was anticipated that changes would be non-trivial, it was believed that accepting red-lines prior to making new proposed edits would improve the readability of this latest draft.

 

For Item 3, we will further discuss plans for the sessions scheduled for day 1 of ICANN63, Saturday 20 October (see the published schedule here: https://63.schedule.icann.org/meetings [63.schedule.icann.org]). 

  

Those signed up as Members to this PDP WG should have received meeting information from the SOAC Support team. If you did not receive these participation details or if you would like to send your apologies, please contact the SOAC Support team (gnso-secs@icann.org).

 

Best,

Steve 2

 

 

Steven Chan


Policy Director, GNSO Support

 

ICANN

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536


Mobile: +1.310.339.4410

Offic
 

e Telephone: +1.310.301.5800

Office Fax: +1.310.823.8649

 

Find out more about the GNSO by taking our interactive courses [learn.icann.org] and visiting the GNSO Newcomer pages [gnso.icann.org].

 

Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO [twitter.com]

Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ [facebook.com]

http://gnso.icann.org/en/ [gnso.icann.org]

 

 

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.