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... 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.
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.
Greg, thanks for the feedback - highly appreciated.
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".
[Alexander Mayrhofer] The AWIP also says that registries must "provide a link or URL next to each EPP status code that directs to an ICANN web page describing and defining the respective EPP status code". Clearly, if the EPP status codes should conform to the EPP documents, adding that link to the "value" side of the Status lines would violate that requirement. More specifically, Is Domain Status: serverDeleteProhibited http://www.icann.org/epp#serverDeleteProhibited conforming, or is it not? I think that the "Clarifications" should be more precise about the relation of those two sets of requirements.
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.
[Alexander Mayrhofer] Well, Section I. clearly says: "The following clarifications apply to both Registry and Registrar Registration Data Directory Services specifications" and Section I.1 says: "All fields (e.g., rows) described in section 1.4.2 of the RDDS spec of the 2013 RAA, and sections 1.5, 1.6, and 1.7 of Specification 4 of the Registry Agreement MUST be shown" English is not my first language, but i don't think that's overly precise if the above sentence should mean that the RAA fields only need to be displayed by Registrars.. Particularly since the whole document intends to "Clarify" things ;-)
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.
[Alexander Mayrhofer] That's a point i was wondering as well. Do we need to show the empty Nameserver: field 13 times (if we allow 13 nameservers per delegation), or just once?
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.
[Alexander Mayrhofer] Coming from the technical side, i simply don't know. However, i was concerned about *preventing* this from the technical side, even before any Registry could actually apply for a waiver... I have one more issue that came to my mind recently: The Clarifications could *really* benefit from explaining the desired WHOIS output in case a registry allows both "int" and "loc" contact postalinfo information. For example, in a case where a domain name is associated with both Contact address types, should the WHOIS output be Registrant Street: Hoehenstrasse 7 (Höhenstraße 7) or rather Registrant Street (int): Hoehenstrasse 7 Registrant Street (loc): Höhenstraße 7 or rather Registrant Street: Hoehenstrasse 7 (int) Registrant Street: Höhenstraße 7 (loc) Or should it be up to the Registry to define which set of fields to display? How should the order of the keys in such contact information be? The "int" set first, then the "loc" set, or "mixed together"? Some Clarification in that area would be greatly appreciated. Also, i would appreciate any pointers where the issues mentioned in the Clarification were discussed publicly. thanks, Alex
participants (2)
-
Alexander Mayrhofer -
Greg Aaron