- gtld-tech - lists.icann.org

Draft Updated WHOIS Clarification Advisory v.20141209
by Gustavo Lozano Dec. 21, 2014

Dec. 21, 2014

Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201 4-09-12-en). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux(a)icann.org. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN

11 19

Re: [gtld-tech] host attributes issue
by Loesje Hermans Dec. 16, 2014

Dec. 16, 2014

Dear Francisco, After the conf call on the WHOIS clarifications I would like to clarify the issues we experience with host attributes and the current specs from ICANN about WHOIS. Since we are using the host attributes instead of host objects, we do not have a sponsoring registrar for hosts. According to the spec 4 of the registry agreement we do need to output these data in case of a nameserver query. In case we have a domain name in the zone that holds glue for a certain host, we could use the data of the sponsoring registrar of that domain name to output in the results of the nameserver query. But that will definitely not be the case for every host. What to display for the fields ‘Registrar’, ‘WHOIS server’ and ‘Referral URL’ in those cases? We also have no ROIDs for hosts. That leaves us with the only option of implementing clarification 32 and return all matching records. This will look weird since we have no data to fill in except for the Server name and the IP Address. As mentioned before, we do not have sponsoring registrars so the rest of the output fields will remain empty or will not be shown. Registrars will be enforced to specify glue when they specify a nameserver in the same domain as the domain name. Therefor we can only have multiple matches when performing a WHOIS query on IP address. Wouldn’t it be more logic to show all possible server names without any other keys in this case? Since the search was on IP, it is not really needed to output this IP address in every record. It would shorten the output and narrow it down to the relevant information. Kind regards, Loesje Hermans Functional Analyst +32 16 29 89 23 DNS Belgium vzw/asbl Ubicenter - Philipssite 5, bus 13 - 3001 Leuven www.dnsbelgium.be<http://www.dnsbelgium.be/> [cid:09ee086c0b7e41ef0f09e359060c1a61f817d422@zimbra]

1 0

Re: [gtld-tech] gtld-tech Digest, Vol 20, Issue 6
by Wodjenski, Sharon Dec. 12, 2014

Dec. 12, 2014

In addition to Alex's comments, I have the following questions/notes: I24. Fields in Whois output MUST NOT appear multiple times, unless otherwise explicitly specified. * Does this mean that only 1 Tech Contact can be displayed? If so, which one should be displayed if there are multiples? I was also especially confused by I29, 30, and 32 for reasons Alex mentions. II40. Responses to registrar object queries MUST show at least one admin contact and one technical contact. * Admin and Technical Contacts for Registrar are optional. So while there can be multiples, there also may be none. -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of gtld-tech-request(a)icann.org Sent: Friday, December 12, 2014 7:00 AM To: gtld-tech(a)icann.org Subject: gtld-tech Digest, Vol 20, Issue 6 Send gtld-tech mailing list submissions to gtld-tech(a)icann.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_l… or, via email, send a message with subject or body 'help' to gtld-tech-request(a)icann.org You can reach the person managing the list at gtld-tech-owner(a)icann.org When replying, please edit your Subject line so it is more specific than "Re: Contents of gtld-tech digest..." Today's Topics: 1. Re: Draft Updated WHOIS Clarification Advisory v.20141209 (Naoki Kambe) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Dec 2014 15:35:28 +0900 (JST) From: Naoki Kambe <kambe(a)jprs.co.jp> To: gtld-tech(a)icann.org Subject: Re: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Message-ID: <20141212.153528.200378422.kambe(a)jprs.co.jp> Content-Type: Text/Plain; charset=us-ascii Hi, One quick comment: One of the objectives of these clarifications is to retain the ability to easily parse the output. Interested users are encouraged to consider the clarifications below when developing parsers for RDDS output. The above objective doesn't seem much different from RDAP's one. I'm afraid the clarified WHOIS specification might reduce motivation to support RDAP. I'm curious about how we would migrate between WHOIS and RDAP in future. Regards, Naoki Kambe ------------------------------ _______________________________________________ gtld-tech mailing list gtld-tech(a)icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_l… End of gtld-tech Digest, Vol 20, Issue 6 ****************************************

1 0

WHOIS clarification needed for host attributes
by Loesje Hermans Nov. 28, 2014

Nov. 28, 2014

Hi all, According to the spec 4 of the registry agreement we should output following fields when querying for a name server: Registrar, WHOIS server and Referral URL. If I understand correctly they are also obligated and therefor cannot be left blank. Which data should be displayed for those fields when the registry uses host attributes? I cannot think of anything logic. Are there other registries using host attributes? Kind regards, Loesje Hermans Functional Analyst +32 16 29 89 23 DNS Belgium vzw/asbl Ubicenter - Philipssite 5, bus 13 - 3001 Leuven www.dnsbelgium.be<http://www.dnsbelgium.be/> [cid:09ee086c0b7e41ef0f09e359060c1a61f817d422@zimbra]

1 0

Call for Presentations for TechDay 26 at ICANN Singapore
by Dr Eberhard Lisse Nov. 27, 2014

Nov. 27, 2014

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Singapore. This time we are considering to try and demonstrate how to generate DNSSEC keys in low cost smartcards which can be used in openDNSSEC and the like. Not a signing ceremony proper, but with a write-up so it is a step towards fully auditable procedures. We'll ask for a (or the same) room for Sunday (afternoon), so we can practice :-)-O Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. African participants are in particular encouraged to present, as are of course Asians :-)-O Please forward this to gNSO and other lists as well :-)-O el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

1 0

Whois advisory feedback meeting @IETF91
by Gustavo Lozano Nov. 26, 2014

Nov. 26, 2014

Hello Colleagues, If you are at the IETF91, an informal meeting to get feedback about the Whois advisory published by ICANN (i.e. https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201 4-09-12-en), will take place at Tapa Tower - Iolani 3 on Thursday (15.00 to 16.30 local time). Please send me a email if you are planing to assist in order to validate that the capacity of the room is sufficient. Regards, Gustavo ICAN

16 25

Name Collision Addendum - "Affected Names"
by Alexander Mayrhofer Nov. 25, 2014

Nov. 25, 2014

I've been reading through the Name Collision Occurrence Assessment Addendum, and one of the key issues seems to identify the "Affected Names" subset of the SLD block list. The Addendum specifies that "Affected Names" are "names that were included in the SLD Block list .... and recorded in the Trademark Clearinghouse ... that registry operator withheld from allocation during the Sunrise period", so it's a set operation between three lists. The SLD Block list as well as the list of names that registry operator withheld from allocation during Sunrise are known to the registry. However, the third list ("recorded in the Trademark Clearinghouse") is unknown to the registry operator, and the DNL is only an approximation. I do understand that such a list actually exists in the TMCH (the "SMDL", as far as i know?), however, this list is only available to registries that were granted a qualified launch program. Therefore, how would a registry that has not applied for a Qualified Launch Program access the SMDL to subsequently build the list of "Affected Names"? Does ICANN intend to release the SMDL to all registries? thanks, Alex

2 1

Almost Final Agenda for the joint DNS-OARC 25th TechDay
by Dr Eberhard W Lisse Nov. 5, 2014

Nov. 5, 2014

As usual I herewith post an almost final Agenda for the upcoming TechDay at the ICANN meeting in LA It is the 25th TechDay and will be held jointly with DNS-OARC. Please review https://indico.dns-oarc.net/conferenceTimeTable.py?confId=20#20141013.detai… for the definitive schedule on Sunday if it differs from this, their version is correct. If they differ on Monday this one or a subsequent one, is correct. Please do not however that somehow they'll manage to squeeze Roy Arends' most excellent Bumblebee demonstration in on Sunday. el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

2 1

FW: New Release of the Registry Reporting Interface
by Kal Feher Oct. 30, 2014

Oct. 30, 2014

Please note the upgrade time and the proposed functional changes. Please disseminate as appropriate. -- Kal Feher Enterprise Architect ARI Registry Services Level 8, 10 Queens Road Melbourne Victoria Australia 3004 Ph: +61 3 9866 3710 Fax: +61 3 9866 1970 Skype: Kal_ausreg Email: kal.feher(a)ariservices.com<mailto:kal.feher@ariservices.com> Web: www.ariservices.com<http://www.ariservices.com> For the latest Domain Name updates, follow us on Twitter @ARIservices The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain privileged and/or confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From: registries-api-bounces(a)icann.org [mailto:registries-api-bounces@icann.org] On Behalf Of Brett Carr Sent: Wednesday, 29 October 2014 2:39 AM To: registries-api(a)icann.org Subject: [ICANN Ry/DEA API] New Release of the Registry Reporting Interface The Production Registry report Interface system will be upgraded to version 1.1.1 on Tuesday the 11th of November between 18:00-19:00 UTC *The following features will be added* Implement a HEAD on https://ry-api.icann.org/report/escrow-agent-notification/<TLD>/<d…> that provides the latest received escrow agent notification from the Data Escrow Agent. Implement a status report showing ok or fail for Escrow reports at /info/status/registry/<tld> Implement a status report showing ok or fail for Escrow reports at /info/status/dea/<tld> Implement HEAD on https://ry-api.icann.org/report/registry-functions-activity/TLD/date to allow simple monitoring Implement a HEAD on https://ry-api.icann.org/report/registry-escrow-report/TLD/date to allow simple monitoring Implement HEAD on https://ry-api.icann.org/report/registrar-transactions/TLD/date to allow simple monitoring Updates to the DNS registry reporting fields to allow higher numbers. *The following issues are resolved* Issue related to db locking when uploading several reports in parallel. A new internet draft will be published and posted on this mailing list prior to the release. - Brett Carr ICANN Technical Services UK (08:00-16:30 UTC)

1 1

Whois Clarifications confusion
by Kal Feher Oct. 16, 2014

Oct. 16, 2014

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

2 4