<html xmlns:v="urn:schemas-microsoft-com:vml" 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 http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
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;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-AU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:black">Hello GTLD-tech folks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">I&#8217;ve been reviewing the Whois Clarifications communication from ICANN and I find myself frustrated at the lack of complete material and at the additional confusion it introduces. I&#8217;ll list the concerns I have below.
 To which I&#8217;d invite any further clarifications from the people on this list: <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Clarification 1. The fields which are explicitly listed are allowed to be blank if they have no data. But what of those fields not listed? Are those fields not allowed to be blank? It should be noted that the EPP
 RFCs&nbsp; have &#8220;voice&#8221; as an optional element, yet it is excluded from Clarification 1 as one of the fields allowed to be blank. It concerns me that a clarification document is trying to introduce new behaviour. If OPTIONAL elements are to become required, a public
 discussion should be had.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Already raised within this list is the confusion around name server addresses. And consider that if you allow multiple IP addresses as well as both IPv4 and IPv6 for each name server.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Clarification 6.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Clarification 7. If IP addresses are provided for name servers, should they appear directly after the name server or at the end of the output? If they appear at the end of RDDS output, it will be difficult for
 a consumer to know which IP address relates to which name server with any confidence. Note the comments for Clarification 1. There will be no reliable way to determine which IP address belongs to which name server.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal">Clarification 8. Hosts may be added without IP addresses. Domains may be assigned&nbsp;to hosts without IP addresses. This is legal behaviour. Therefore requiring that a whois for a name server contain IP addresses, when system behaviour does
 not have a matching requirement, is contradictory. If system behaviour is to change, then it should done so through a public discussion. This is not a clarification, rather it is an alteration of existing behaviour.<o:p></o:p></p>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Clarification 10. The requirement to order fields as displayed, may need additional information and clarification. My literal interpretation of the requirements leads me to think that a second Admin or Tech contact
 would be displayed after the end of all RDDS output. An alternate reading is that we repeat each key in order eg: &nbsp;&#8220;Admin Name: AdminOne&#8221; followed by &#8220;Admin Name: AdminTwo&#8221;. That is likely to confuse consumers significantly more than grouping a single complete
 Admin contact together followed by the next Admin contact and so on. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">It appears these clarifications have not been thought through in terms of they will be consumed and &nbsp;interpreted. Nor do they appear to have been developed with a view to ensuring that Registries and Registrars
 now&nbsp; have a complete picture of their Whois output obligations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal">I&#8217;m sure the clarifications are clear in the author&#8217;s mind. But we as consumers of the document are left to guess. My experience with ICANN&#8217;s interpretation of many elements of the Registry Agreement has been that they take an overly literal
 interpretation of what is written. I must therefore do the same when reading their documents. So if there are gaps, regardless of how obvious the solution might be, we have to insist that those gaps in clarity be provided to us.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I echo Alexander&#8217;s request that a complete specification, with no contradictions and no guesses, is required. Otherwise we&#8217;ll be back here again a few months from now, clarifying the clarification document with further behaviour creep and
 with Registrars and Registries wasting further development resources.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">--<o:p></o:p></p>
<p class="MsoNormal">Kal Feher<o:p></o:p></p>
</div>
</body>
</html>