The simplest the best Rubens. Agree those are considerations we shall pursue Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos. HAPPY 2017! From: <gnso-newgtld-wg-wt1-bounces@icann.org> on behalf of Rubens Kuhl <rubensk@nic.br> Date: Monday, February 13, 2017 at 4:17 PM To: "gnso-newgtld-wg-wt1@icann.org" <gnso-newgtld-wg-wt1@icann.org> Subject: Re: [Gnso-newgtld-wg-wt1] Systems and Communications recommendations from the New gTLD Program Implementation Review Em 1 de fev de 2017, à(s) 13:40:000, Emily Barabas <emily.barabas@icann.org<mailto:emily.barabas@icann.org>> escreveu: Dear WT 1 members, As discussed on yesterday’s call, the New gTLD Program Implementation Review provides several recommendations that the group may want to consider in developing implementation guidance on Systems and Communications. The following text is excerpted directly from the report (available at https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf): Systems (see page 174) …there are additional considerations from this round that can be used to inform the next round. In particular, the system development process many have benefited from leveraging industry standard best practices for product development. In this round, there was limited time available between the finalization of system requirements and the launch of the TLD Application System. In future application rounds, the Program timeline should provide additional time for system development, including the definition of robust system requirements and appropriate testing. In summary: 8.1.a In developing timelines for future application rounds, provide an appropriate amount of time to allow for the use of best practices in system development. 8.1.b Explore beta testing programs for systems to allow for lessons learned, to increase effectiveness of such systems, and to provide further transparency, clarity, and opportunity for preparation to applicants. Note that this is one way of seeing it. The other, which is shared among many technical people working for 2012 applicants, is that the system was made too complex, so it was inevitable that it would either have flaws or require skilled construction and more time to test. For instance, instead of a web interface, the system could accept a simple "tarball" (an archive of some sort, of which .zip is the mostly known although .tar more used at back-end systems) and process it. A web interface could be available to show what the system has received, so applicants could verify integrity and completeness, but it would be an easier interface to build securely. So, more time and more skilled artisans are one of doing it; the other is doing it simple. Rubens