Hi All, Review of 2014 New gTLD Registry Agreement https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved... <https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved...> From Specification 4, Section 1.4, 1.6, and 1.7 1.4 : “The fields specified below set forth the minimum output requirements. Registry Operators may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.” 1.6: “Registrar Data Registrar Name Registrar Postal Address Registrar Phone Number Registrar Email Address WHOIS Server Referral URL Admin Contact Information (phone number and email) Technical Contact Information (phone number, email)” 1.7: "Nameserver Data Server Name IP Address (1 or more, IPv4 and/or IPv6) Registrar Name Registrar WHOIS Server Referral URL" Charter Question "Data Elements What data should be collected, stored, and disclosed." The text requires that registries provide registrar information and contact details as part of a registrar query on the WHOIS, as well as registrar information as part of the nameserver WHOIS query. From Specification 4, Section 1.8 and 1.9 1.8: "The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers (the extension will be provided as a separate field as shown above), email addresses, date and times should conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.” 1.9: “In order to be compatible with ICANN’s common interface for WHOIS (interNIC), WHOIS output shall be in the format outlined above” The text outlines the standards to be implemented when formatting output as part of a WHOIS query. Charter Question “Data Elements” and potentially “Data Accuracy”. Although I think this could be a new requirement for “standardisation” of information. From Specification 4, Section 1.10 1.10: "Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section. 1.10.1 Registry Operator will offer searchability on the web-based Directory Service. 1.10.2 Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.). 1.10.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). 1.10.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT. 1.10.5 Search results will include domain names matching the search criteria. 1.10.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies. Charter Question Could be linked to “User/Purpose”, “Compliance” and “System Model” From Specification 6, Section 1 1: "Standards Compliance: For DNS, EPP, DNSSEC, IDN, IPv6" The text provides clarity on what standards and how to implement the standards for operation. Charter Question “Data Elements”, “Compliance”, “System Model" and potentially a new section on “standardisation”. From Specification 10, Section 4 4: "RDDS 4.1. RDDS availability. Refers to the ability of all the RDDS services for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the RDDS testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable. 4.2. WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined. 4.3. Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request. If Registry Operator implements a multiple-step process to get to the information, only the last step shall be measured. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined. 4.4. RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-based- WHOIS query RTT”. 4.5. RDDS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made. 4.6. RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the RDDS services. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDDS test are: a number in milliseconds corresponding to the RTT or undefined/unanswered. 4.7. Measuring RDDS parameters. Every 5 minutes, RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each RDDS service of the TLD being monitored and make an “RDDS test” to each one. If an “RDDS test” result is undefined/unanswered, the corresponding RDDS service will be considered as unavailable from that probe until it is time to make a new test. 4.8. Collating the results from RDDS probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs. 4.9. Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links." The text outlines how compliance for the RDDS will be measured by ICANN currently. If any changes to the current system are to be made, these compliance measures have to be reviewed, or worked with. Charter Question “System Model” and “Compliance” Regards, Vlad Dinculescu