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

[Alexander Mayrhofer]

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