Whois Clarifications confusion
Hello GTLD-tech folks, I've been reviewing the Whois Clarifications communication from ICANN and I find myself frustrated at the lack of complete material and at the additional confusion it introduces. I'll list the concerns I have below. To which I'd invite any further clarifications from the people on this list: Clarification 1. The fields which are explicitly listed are allowed to be blank if they have no data. But what of those fields not listed? Are those fields not allowed to be blank? It should be noted that the EPP RFCs have "voice" as an optional element, yet it is excluded from Clarification 1 as one of the fields allowed to be blank. It concerns me that a clarification document is trying to introduce new behaviour. If OPTIONAL elements are to become required, a public discussion should be had. Already raised within this list is the confusion around name server addresses. And consider that if you allow multiple IP addresses as well as both IPv4 and IPv6 for each name server. Clarification 6. Clarification 7. If IP addresses are provided for name servers, should they appear directly after the name server or at the end of the output? If they appear at the end of RDDS output, it will be difficult for a consumer to know which IP address relates to which name server with any confidence. Note the comments for Clarification 1. There will be no reliable way to determine which IP address belongs to which name server. Clarification 8. Hosts may be added without IP addresses. Domains may be assigned to hosts without IP addresses. This is legal behaviour. Therefore requiring that a whois for a name server contain IP addresses, when system behaviour does not have a matching requirement, is contradictory. If system behaviour is to change, then it should done so through a public discussion. This is not a clarification, rather it is an alteration of existing behaviour. Clarification 10. The requirement to order fields as displayed, may need additional information and clarification. My literal interpretation of the requirements leads me to think that a second Admin or Tech contact would be displayed after the end of all RDDS output. An alternate reading is that we repeat each key in order eg: "Admin Name: AdminOne" followed by "Admin Name: AdminTwo". That is likely to confuse consumers significantly more than grouping a single complete Admin contact together followed by the next Admin contact and so on. It appears these clarifications have not been thought through in terms of they will be consumed and interpreted. Nor do they appear to have been developed with a view to ensuring that Registries and Registrars now have a complete picture of their Whois output obligations. I'm sure the clarifications are clear in the author's mind. But we as consumers of the document are left to guess. My experience with ICANN's interpretation of many elements of the Registry Agreement has been that they take an overly literal interpretation of what is written. I must therefore do the same when reading their documents. So if there are gaps, regardless of how obvious the solution might be, we have to insist that those gaps in clarity be provided to us. I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required. Otherwise we'll be back here again a few months from now, clarifying the clarification document with further behaviour creep and with Registrars and Registries wasting further development resources. -- Kal Feher
Clarification 1. The fields which are explicitly listed are allowed to be blank if they have no data. But what of those fields not listed? Are those fields not allowed to be blank? It should be noted that the EPP RFCs have "voice" as an optional element, yet it is excluded from Clarification 1 as one of the fields allowed to be blank. It concerns me that a clarification document is trying to introduce new behaviour. If OPTIONAL elements are to become required, a public discussion should be had.
All fields are mandatory unless option, excluding those that can be blank, or errors in the specification ;) Or in English * optional fields - dont output the label & data if the data is not provided * fields explicity mentioned as allowed to be blank - output the label but no data if the data is not provided * everything else - output the label and the data
Clarification 7. If IP addresses are provided for name servers Clarification 8. Hosts may be added without IP addresses.
For self-referencing domains (glue) output the label, IP and FQDNs otherwise just label and FQDN
I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required.
Yes, and that doenst contradict the *contract* Rob
Thank you Rob for taking the time to respond. Further comments in line.
Clarification 1. The fields which are explicitly listed are allowed to be blank if they have no data. But what of those fields not listed? Are those fields not allowed to be blank? It should be noted that the EPP RFCs have "voice" as an optional element, yet it is excluded from Clarification 1 as one of the fields allowed to be blank. It concerns me that a clarification document is trying to introduce new behaviour. If OPTIONAL elements are to become required, a public discussion should be had.
All fields are mandatory unless option, excluding those that can be blank, or errors in the specification ;) Or in English * optional fields - dont output the label & data if the data is not provided * fields explicity mentioned as allowed to be blank - output the label but no data if the data is not provided * everything else - output the label and the data KF - You and I have subtly different interpretations of Clarification 1. It says _all_ fields in 1.5 of the RA ("phone number" being one of them) MUST be shown in the output. So we don't have an option to not show the key. Only an option to show no data if no data exists. This then runs afoul of the explicit listing of those keys for which having no data is acceptable (phone number this time not present). So your first point is one that my reading of the clarification suggests is not a valid option, much as I'd like it to be.
Clarification 7. If IP addresses are provided for name servers Clarification 8. Hosts may be added without IP addresses.
For self-referencing domains (glue) output the label, IP and FQDNs otherwise just label and FQDN KF - It is perfectly legal to have no IP address for a host and to assign a domain to such a host. While DNS may not work in this instance, at least for the name server concerned, it is nevertheless legal behaviour. Again we have a "MUST" for outputting optional data. I think such a case was not considered when writing the clarification. I would argue however that a clarifications communication should take all such corner cases into account, lest they contradict system behaviour.
I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required.
Yes, and that doenst contradict the *contract* KF - completely agree. Rob
All fields are mandatory unless optional, excluding those that can be blank, or errors in the specification ;) Or in English * optional fields - dont output the label & data if the data is not provided * fields explicity mentioned as allowed to be blank - output the label but no data if the data is not provided * everything else - output the label and the data
KF - You and I have subtly different interpretations of Clarification
Where a 'clarification' contradicts the _contract_ then as the contact is the thing that is 'binding', I would always go with that :) Contract = what you must do, Clarifications tend to = 'we'd like this and use it to sneak things in the back-door'
Clarification 7. If IP addresses are provided for name servers Clarification 8. Hosts may be added without IP addresses. For self-referencing domains (glue) output the label, IP and FQDNs otherwise just label and FQDN KF - It is perfectly legal to have no IP address for a host and to assign a domain to such a host.
Not for any gTLD that I'm aware of - the registry will reject it at time of registration (happens *very* frequently according to my epp error logs)
I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required. Yes, and that doenst contradict the *contract* KF - completely agree.
Rob
Thank you again Rob for your feedback. I've commented on your points in line. I think the fact that so much interpretation and speculation is required, for what was supposed to be a list of clarifications, indicates that this process needs to be rethought. If there are system behaviour scenarios that ICANN does not like, then a separate discussions should occur on those. There may be repercussions much larger than originally perceived. -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of rob.golding@astutium.com Sent: Wednesday, 15 October 2014 6:13 PM To: gtld-tech@icann.org Subject: Re: [gtld-tech] Whois Clarifications confusion
All fields are mandatory unless optional, excluding those that can be blank, or errors in the specification ;) Or in English * optional fields - dont output the label & data if the data is not provided * fields explicity mentioned as allowed to be blank - output the label but no data if the data is not provided * everything else - output the label and the data
KF - You and I have subtly different interpretations of Clarification
Where a 'clarification' contradicts the _contract_ then as the contact is the thing that is 'binding', I would always go with that :) Contract = what you must do, Clarifications tend to = 'we'd like this and use it to sneak things in the back-door' KF - I suspect our experiences differ, which probably influences my perception of the likelihood of such an approach working. Unfortunately our recent experiences with ICANN have shown a very literal interpretation of all documents, to the point of absurdity. I think Registries may be at a disadvantage here because the output will be assessed during PDT, leaving us no room for such an argument.
Clarification 7. If IP addresses are provided for name servers Clarification 8. Hosts may be added without IP addresses. For self-referencing domains (glue) output the label, IP and FQDNs otherwise just label and FQDN KF - It is perfectly legal to have no IP address for a host and to assign a domain to such a host.
Not for any gTLD that I'm aware of - the registry will reject it at time of registration (happens *very* frequently according to my epp error logs) KF - You can register a domain without hosts. You can create hosts without IP addresses. You can then update a domain to point to such hosts. And this doesn't have to be restricted to subordinate hosts, though that appears to be the only circumstance considered in the communication. Consider domain1.example delegated to ns.domain2.example and domain2.example delegated to ns.domain1.example. I think whois should simply report what is in the registry. Therefore, optional elements need to be allowed to be empty.
I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required. Yes, and that doenst contradict the *contract* KF - completely agree.
Rob
participants (2)
-
Kal Feher -
rob.golding＠astutium.com