<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Title content=""><meta name=Keywords content=""><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Arial;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.msoIns
        {mso-style-type:export-only;
        mso-style-name:"";
        text-decoration:underline;
        color:teal;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:595.0pt 842.0pt;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Dear Work Track members,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Please see below the notes from the meeting today.  <i>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 or transcript.</i> See the chat transcript and recording at: <a href="https://community.icann.org/x/VAtyB">https://community.icann.org/x/VAtyB</a>.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Slides are attached for reference.<o:p></o:p></p><p class=MsoNormal><b> </b><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Kind regards,<o:p></o:p></p><p class=MsoNormal>Julie<o:p></o:p></p><p class=MsoNormal>Julie Hedlund, Policy Director<o:p></o:p></p><div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='border:none;padding:0in'> <o:p></o:p></p></div><p class=MsoNormal><b><span style='color:black'><o:p> </o:p></span></b></p><p class=MsoNormal><b><span style='color:black'>Notes/Action Items:<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='color:black'><o:p> </o:p></span></b></p><p class=MsoNormal>1. SOIs: No updates.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>2. Review of potential recommendations for Systems & Communications:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 4: Systems:<o:p></o:p></p><p class=MsoNormal>-- Issue posed to the WG: How can the systems used to support the New gTLD Program, such as TAS, Centralized Zone Data Service, Portal, etc. be made more robst, user friendly, and better integrated?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 5: Systems recommendations<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 6: System recommendations -- Consensus items to date<o:p></o:p></p><p class=MsoNormal>-- ICANN's Program Implementation Review Report has some relevant information on page 168: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf<o:p></o:p></p><p class=MsoNormal>-- Can we show that some of the concerns from the first round are being addressed?  Can add some language on the improvements that have already been addressed.<o:p></o:p></p><p class=MsoNormal>-- On the beta testing -- good recommendation -- there was a feeling that if we had done some beta testing ICANN might think that those who did the testing would have an unfair advantage.  If we do recommend beta testing we should address that issue.<o:p></o:p></p><p class=MsoNormal>-- Add another note saying that the system shouldn't add new legal requirements, such as click-through agreements.<o:p></o:p></p><p class=MsoNormal>-- If there is a new system there will need to be new terms of use that may impose new legal requirements.  We can express concern and reflect on what happened previously but it's unrealistic that a new system would not have any legal privileges and obligations.<o:p></o:p></p><p class=MsoNormal>-- Any legal conditions should be known up front in the AGB.  Should be finalized before the process.<o:p></o:p></p><p class=MsoNormal>-- Shouldn't be the unilateral imposition of new legal terms and conditions -- should be a negotiated process.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>From the chat:<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): last time systems were not very secure - it is possible to add sowrding about separation of info recieved from different logins?<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): wording<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): it was large scale issue<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): As I understand current Portal is going to accept info of Applicants, and not just Registies like now, and it is full of issues, and testing was a failure .. almost nothing was fixed after it<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): so I am really pessemistic about the improvements done<o:p></o:p></p><p class=MsoNormal>Donna Austin, Neustar: Jeff, I understand that but there has been improvements/changes that might be positive.<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): and we participated in the pilot<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): the engagement without learning <o:p></o:p></p><p class=MsoNormal>Jeff Neuman: I do not believe the new portal can handle the receipt of application data<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): was last time (autmn)<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): even the import of data from the old GDD portal was not done properly<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): that is why I recommended to add the wording about separation of data<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): another important item: the system should not add new legal requirements on itself <o:p></o:p></p><p class=MsoNormal>Jeff Neuman: I agree 100% with Maxim.  We are still dealing with this on the new portal where 50% of us have not used it because of the Terms of Use<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: "Homogenous terms and conditions between AGB and application system", perhaps ? <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): legal requrements, which were not written in AGB or policies<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): I meant these requirements needs to be driven from the multistakeholder process and needs to be set in advance<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): or required changes to these terms - matter of IRT of something like it<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 8: Communications<o:p></o:p></p><p class=MsoNormal>-- Issue posed to the WG: Examine access to and content within knowledge base as well as communication methods between ICANN and the community.<o:p></o:p></p><p class=MsoNormal>-- The data in these slides comes from the Program Implementation Review Report as well: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf  You can see the relevant sections starting on page 199<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 9: Customer Service Center (CSC)<o:p></o:p></p><p class=MsoNormal>-- Around 2200 were on TLD application status.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 10: CSC Annual Volume of Cases<o:p></o:p></p><p class=MsoNormal>Slide 11: CSC Number of Days to Last Response<o:p></o:p></p><p class=MsoNormal>Slide 12: CSC Number of Days to Case Closure<o:p></o:p></p><p class=MsoNormal>Slide 13: CSC Percentage of Cases Resolved by Tier 1<o:p></o:p></p><p class=MsoNormal>Slide 14: Communication Recommendations<o:p></o:p></p><p class=MsoNormal>Slide 15: Communications Recommendations -- Consensus Items to Date<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Discussion:<o:p></o:p></p><p class=MsoNormal>-- Slide 15 -- "Program information should be contained within one website" -- Last time everything was spread around and not easy to find.<o:p></o:p></p><p class=MsoNormal>-- Prioritize the issues that have the biggest impact for most people.<o:p></o:p></p><p class=MsoNormal>-- Need for an escalation procedure.<o:p></o:p></p><p class=MsoNormal>-- This is another area where it may help to provide policy guidance on the ability of ICANN to answer questions without treating one applicant more favorably.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>From the chat:<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): prioritization of cases is required - like non-working application system  - first grade e.t.c.<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): in the future system<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): there were no SLAs - they were created as a result of common interest working group of GDD and Registries/Applicants group<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): *result of work<o:p></o:p></p><p class=MsoNormal>Jeff Neuman: I had that issue<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): there should be an escalation process in place<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): with clear rules and timelines<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): notifications to applicants<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): also when applicants know already open info - it saves time of support team<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>3. Review of potential recommendations for Application Queuing<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 17: Application Queuing<o:p></o:p></p><p class=MsoNormal>-- Issue posed to this WG: Review whether first come first served guidance remains relevant and if not, whether another mechanism is more appropriate.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 18: Applicant Queuing Recommendations<o:p></o:p></p><p class=MsoNormal>-- If queuing need support draw/raffle, not Digital Archery.<o:p></o:p></p><p class=MsoNormal>-- Allow applicants which of their applications to prioritize.<o:p></o:p></p><p class=MsoNormal>-- No consensus on prioritization.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 19: Applicant Queuing Recommendations -- Consensus Items to Date<o:p></o:p></p><p class=MsoNormal>-- Not sure asking what the goals were is very helpful. Not sure if the goal was to have IDNs go first. <o:p></o:p></p><p class=MsoNormal>-- Need to consider what we gain from prioritization of applications.  Prioritizaton of IDNs made sense at the time but caused problems and delays.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>From the chat:<o:p></o:p></p><p class=MsoNormal>Steve Chan: Ok, maybe we can formulate that into a fully formed request and then WT1 can help determine if it's something it needs to explore.<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: Perhaps WT1 could establish no opposition but no request to prioritze IDNs. That ICANN would have liberty to decide whether the political scenario at that time favors doing IDN prioritization or not. <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): if some special priorities identified, we should use soemthing like "Weighted Fair Queueing"<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): https://en.wikipedia.org/wiki/Weighted_fair_queueing<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): so the prioritized group of application does not block others completely<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): *applications<o:p></o:p></p><p class=MsoNormal>Donna Austin, Neustar: rather than IDNs should we give some preference to applications from the global south?<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): @Donna, I meant something like this - but using the transparent process<o:p></o:p></p><p class=MsoNormal>Alexander Schubert: Global South will be gamed as tons of applicants use shell companies in tax havens anyways!<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): maybe , last time lots of offshore companies were from "Europe"<o:p></o:p></p><p class=MsoNormal>Donna Austin, Neustar: quite possibly Alexander<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): in terms of regions (for applications)<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: Not creating high barriers like high application fees and high recurring yearly fees is what would help Global South without being gamed. <o:p></o:p></p><p class=MsoNormal>Christa Taylor: Were IDN applicants who were given priority given a choice?<o:p></o:p></p><p class=MsoNormal>Christa Taylor: yes<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): @ Rubens, it will be possible to rent out such registries after the process<o:p></o:p></p><p class=MsoNormal>Alexander Schubert: Low monetary entry barriers will create fun-applications by wannabe registries.<o:p></o:p></p><p class=MsoNormal>Christa Taylor: So are we against the priortization of applications?<o:p></o:p></p><p class=MsoNormal>Steve Chan: @Christa, I believe the order was 1) IDNs that opted in 2) standard TLDs that opted in 3) IDNs that did NOT opt in and 4) standard TLDs that did NOT opt in<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): @Christa, we are not against it, it should be done in transparent manner, using different priorities for approved groups of applications (if any)<o:p></o:p></p><p class=MsoNormal>Jeff Neuman: No one has presented a compelling case for prioritizing any types of applications.  We could ask for feedback on this in the Preliminary report.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>