<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div>Besides some specific comments below, the general comment I want to make is that these changes serves no real purpose for the community. They try to define an strict output format that is not required either by any reasonably-implemented parsing interface nor by any reasonable human being. Any undergraduate student can use YACC/Bison to write a parser that could easily grasp for all the possibilities the original agreement, even without clarifications, could generate. BTW, I guess one actual implementation out there (<a href="https://gwhois.org/" class="">https://gwhois.org/</a>) used a much simpler architecture to adequately respond to different registry implementations. <div class=""><br class=""></div><div class="">That said, some specific comments:</div><div class="">- Clarification numbers don't match between the two documents, and sometimes inside the documents the wrong clarification is mentioned. The documents need some revising. </div><div class="">- Host attributes registries were clearly forgotten in the design. There are no ROID's for name servers in host attributes registries, and if IP addresses are removed from domain queries, they won't appear in any query. </div><div class="">- It also assumes registrars have admin/techcontacts. There was no such requirement in the agreements. </div><div class="">- It tries to change a tradition of referral-URL to point to web-whois instead; it's possibly better to keep it the way it's currently used, and instead display port-43 registrar WHOIS server (if available) in port-43 registry WHOIS, but display WEB-WHOIS registrar WHOIS server in registry WEB-WHOIS. </div><div class="">- There are lots of new query types and behaviors; all of them constitute new requirements. They both generate a significant one-time developing workload and also generate compliance risks for registries that don't whether to follow the original agreement or a misplaced clarifications documents that has no basis on the agreement. </div><div class=""><br class=""></div><div class="">My suggestions to improve this process:</div><div class="">- Do not try to establish any type of parameter response order other than being intelligible by a reasonable human being. RDAP is the proper response for syntactically constructed queries and responses. </div><div class="">- Do not force any parameter that is optional to have a blank response. This only makes the WHOIS output less under stable by human beings, which will continue to be the main customers of this information. </div><div class="">- Do not try to force data models that weren't there at the first place, like registrar contacts</div><div class="">- Do not prevent IP addresses from being shown in in-bailwick name servers, although making such behavior optional for host-objects registries</div><div class="">- Do not put any of this in a document called "clarifications". Make them part of the ongoing agreement negotiation between registries and ICANN for the registries part and evoke RAA negotiation for the registrars part, or make all of it part of a consensus policy so all contracted parties act on it simultaneously. Trying to bypass process does not look good here. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Rubens</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Em 09/12/2014, à(s) 22:41:000, Gustavo Lozano <<a href="mailto:gustavo.lozano@icann.org" class="">gustavo.lozano@icann.org</a>> escreveu:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class="">Hello colleagues,</div><div class=""><br class=""></div><div class="">Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (<a href="https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014-09-12-en" class="">https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014-09-12-en</a>).</div><div class=""><br class=""></div><div class="">This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. </div><div class=""><br class=""></div><div class="">A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to <a href="mailto:fabien.betremieux@icann.org" class="">fabien.betremieux@icann.org</a>.</div><div class=""><br class=""></div><div class="">Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.</div><div class=""><br class=""></div><div class="">It's important to remember:</div><div class="">* This advisory is not meant to create new requirements for contracted parties.</div><div class="">* This advisory is not meant to redefine the WHOIS protocol.</div><div class="">* This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.</div></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Gustavo</div><div class="">ICANN</div></div>
<span id="cid:9636A7D7-4508-4DE5-8E2A-2FD5987DDF75"><Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx></span><span id="cid:0097B2D6-AC11-4DDE-850B-29DE6BE3F761"><Registry and Registrar RDDS Advisory - 20141209[3].docx></span></div></blockquote></div><br class=""></div></div></body></html>