[gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209

[Gould, James]

Gustavo,

In reviewing the updated document, I have the following feedback.  Overall, the clarification document attempts to define ICANN’s desired Whois Server behavior.  It is clearly defining new requirements and not providing clarifications to existing ones.  The Thick Whois work may define a completely new set of requirements that may collide with these ever growing set of requirements, and still without any formal specification.  Is there anyway to combine these Whois efforts that considers the existing Whois Server behavior, the desired behavior, and with the goal to define a unified Whois specification that the community can collaborate on and implement to?  Providing clarifications to clarifications based on an incomplete set of requirements in the registry and registrar agreements to eventually form the desired end state for Whois is highly disruptive, highly inefficient, and expensive.  Please take a step back with all of this and come up with a path forward that helps attain the goal of a consistent Whois interface with minimal cost and complexity.  The upcoming RDAP should also be considered with this effort.

Thank you for adding the “2) no field MUST be shown” option for non-existent fields in clarification 1.
Clarification 11 still makes the order of keys significant.  The 2013 RAA and the Registry Agreement do not explicitly state that the order of keys is significant.  The clarification document is defining brand new requirements for ordered display of keys that breaks existing convention.  For example, why put the billing contact information separate from the rest of the contact information?  Why put the Internationalized Domain Name field far away from the Domain Name field?  Why put the Phone Ext and Fax Ext fields of the Registrar contacts far away from the Phone and Fax fields?  As noted previously, the most important item for parsers is for the keys to be the same, where the order is not significant.  My recommendation is to specify just the set of keys and define the format of the values.  
The revised text “(ie. no partial match or other search ability capabilities, only exact match lookup).” in clarification 18 and the new clarification 23 “WHOIS (port-43) queries for name server object MUST NOT offer partial match or other searchable capabilities.”  went in the opposite direction to the feedback provided at IETF-91 and on the gtld-tech list.  Prohibiting existing Whois Server functionality across multiple registries is a new requirement that has not been discussed, has not been justified, and is beyond the scope of a clarifications document.  The partial match functionality has existed for a long time and is a useful feature for clients.  What is the basis for ignoring the feedback and attempting to remove this useful feature in a clarifications document?  As requested previously, please remove clarification 18 and now the new clarification 28.  
New clarification 26 is new behavior.  We currently return ‘No match for “<QUERY>”.’ for non-existent entities.  What do other Whois servers return?  Can we have a discussion around what is the appropriate behavior for queries of non-existent  entities prior to adding a new requirement?  
New item 27 “Domain Name registration MUST have one and only one administration contact” seems to go beyond what is displayed in Whois.  Can you clarify the clarification and also clarify why administration contacts are handled differently from tech and billing contacts?
I believe that clarification 30 should reference clarification 29 instead of 28.
For the new clarification 31, why is partial matching for Registrar data allowed but prohibited for domain and name servers?  Partial match for domain and name servers is existing behavior and more useful.  
I believe that clarification 32 should reference clarification 29 instead of 28.  
New clarification 38 ‘When receiving unqualified query (i.e., a query string that does not include the “nameserver” or “registrar” parameters) that matches a domain name and a name server object, the registry MUST return the information about the domain name object.’ is a new requirement.  Existing Whois implementations return all domain, nameserver, and registrar matches on an unqualified query.  This again is more than a simple clarification, but a fundamental change in Whois Server behavior.
Clarification 40 “Responses to registrar object queries MUST show at least one admin contact and one technical contact” is another new requirement.  At a minimum this should be set as SHOULD instead of MUST. 

Thanks,

—

JG




James Gould
Distinguished Engineer
jgould at Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

On Dec 9, 2014, at 7:41 PM, Gustavo Lozano <gustavo.lozano at icann.org> wrote:

> Hello colleagues,
> 
> 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 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014-09-12-en).
> 
> 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. 
> 
> 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 fabien.betremieux at icann.org.
> 
> 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.
> 
> It's important to remember:
> * This advisory is not meant to create new requirements for contracted parties.
> * This advisory is not meant to redefine the WHOIS protocol.
> * 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.
> 
> Regards,
> Gustavo
> ICANN
> <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20141211/b3352d55/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
Type: image/png
Size: 4109 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20141211/b3352d55/BF09FAA4-32D8-46E0-BED0-CD72F43BD6E081-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4712 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20141211/b3352d55/smime-0001.p7s>