gtld-tech

Download

gtld-tech@icann.org

September 2014

5 participants
2 discussions

ICANNs WHOIS "clarifications" - overreaching and contradicting?
by Alexander Mayrhofer Sept. 18, 2014

Sept. 18, 2014

ICANN has published extensive "WHOIS Service Clarifications" on September 12, posted here: https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201… 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.

2 2

Registry Escrow Policy Object
by John Keating Sept. 15, 2014

Sept. 15, 2014

Hi, There seems to be a discrepancy between the way an Escrow Deposit Policy object is defined. In section 5.8.1 of version 5 of the Object mapping doc it's defined as: The OPTIONAL <policy> contains the following attributes: o An <element> that defines that the referenced <element> is REQUIRED. o <scope> that defines the XPath of the element referenced by <element>. Example of <rdePolicy:policy> object: <rdePolicy:policy scope="//rde:deposit/rde:contents/rdeDomain:domain" element="rdeDom:registrant" /> In rde-policy-1.0.xsd it's defined as: <element name="policy" type="rdePolicy:policyType" substitutionGroup="rde:content"/> <complexType name="policyType"> <complexContent> <extension base="rde:contentType"> <attribute name="element" type="anyURI" use="required"/> </extension> </complexContent> </complexType> Which says it has one attribute named 'element' of type 'anyURI', and the attribute 'scope' is not mentioned and so is not allowed. Has this difference in definitions been mentioned before? Thanks, John

3 10