[gtld-tech] ICANNs WHOIS "clarifications" - overreaching and contradicting?

[Greg Aaron]

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 at icann.org [mailto:gtld-tech-bounces at icann.org] On
Behalf Of Alexander Mayrhofer
Sent: Tuesday, September 16, 2014 5:45 AM
To: gtld-tech at 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.