Dear Alexander: Regarding: 2) I don't see a contradiction. I think the problem that ICANN is trying to address is that some registrars still display old-style, non-EPP status values, especially for .COM and .NET names. The AWIP just said that registrars "only refer to the statuses by their respective EPP status codes". 3) Yes, this was presented in a less-than-clear fashion. It might have been better for ICANN's doc to have two sections only -- one regarding registrars/RAA, and one regarding registries/registry contract, and repeating some things in each. The less interpretation that is necessary, the better. For example, you are correct that the Reseller field is unique to the RAA; it is not listed in the nTLD registry contract Spec 4, and therefore there is no obligation for registries must display that field in their WHOIS output. So I don't think that ICANN is saying that registries must display the reseller field in their WHOIS output. 4) Empty fields have been a feature of some legacy gTLDs' output for some time. (See the thirteen Nameserver fields in .ORG WHOIS output for an example.) This may be an attempt to bring everything into line. 5) Must a registry received a waiver from ICANN in order to not display fields that re marked as mandatory in the contract? Registrars are filing for data waivers, but I don't recall a registry doing so yet. All best, --Greg -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Alexander Mayrhofer Sent: Tuesday, September 16, 2014 5:45 AM To: gtld-tech@icann.org Subject: [gtld-tech] ICANNs WHOIS "clarifications" - overreaching and contradicting? ICANN has published extensive "WHOIS Service Clarifications" on September 12, posted here: https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014 -09-12-en We think that some of the points would warrant discussion among registries/registrars, as well as feedback from ICANN. Specifically, our points are: 1) Relation between current WHOIS requirements and RDAP implementation: Given the progress of RDAP in the IETF, we're wondering why ICANN can justify requesting the industry to put significant effort into modifying existing (and PDT-approved!) implementations of a protocal that ICANN probably intends to replace in the near future anyways. -> Therefore, Please provide a (if preliminary!) view on ICANN's intended roadmap on the future of RDDS protocols. 2) "Incremental", contradicting specifications: It seems like the "clarifications" contradict earlier requests by ICANN to modify the WHOIS service in at least one requirement: Clarification I.5 requires that Domain status field values conform to the respective EPP mappings. However, ICANNs earlier request in the "AWIP" (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en) requires that the line also includes a web link back to an information page - which means that the field value is required to carry cruft that is not contained in the EPP mappings, and hence violates ICANN's own "Clarification". I think this happens because of the "incremental" way the service is specified. -> Please provide an aggregated, complete, standalone specification without any contradicting requirements. 3) RAA specification affecting Registries: It seems weird that Registries should suddenly be subject to requirements that are included in the *RAA*. For example, see the "reseller" field in Clarification 1 - Why on earth would a *Registry* be required to display that field, which would contain information that only the registrar has access to? -> Please re-consider using the loophole of "Clarifications" to apply RAA requirements to registries 4) Redundant "empty" fields: Displaying an empty set of keys (eg. the field "Name Server" for domains, or the various DNSSEC-related fields) makes very little sense to me. Specifically for data relations that have a cardinality of 0..n, the requirement to include *all* fields seems overreaching. It might be sensible for fields that have a 1:1 relation, but artificially adding denormalized field sets for non-existing object relations is sloppy. Particularly because the only reasoning seems that people write cra..^H inadequate parsers. -> Please relax the respective requirement. 5) Data Protection requirements, EPP hidden fields vs. WHOIS: EPP allows for the "hiding" of certain fields in an contact object. The main use for this is (and will be) to achieve compliance with local data protection law, for example for EU based registries. However, the requirement in the Clarification document that "all fields MUST be shown", together with the provision that only "fields for which no information does exist in the registry" can be left empty effectively requires registries to breach the EPP "hidden field" settings. I'm not diving much deeper into the policy side of this, but preventing this from the *technical* side already looks like another loop hole to me. -> Please consider the option to exclude certain fields (particularly those affected by the EPP "hide" policy) on the technical level, to allow for doing so should a current or future policy allow (or a legal ruling to require) registries to do so. Feedback and discussion appreciated. thanks, Alex Mayrhofer Head of R&D nic.at / TLDBOX GmbH.