- gtld-tech - lists.icann.org

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

Publishing of the Allocation Token EPP Extension IETF Draft
by Gould, James Oct. 9, 2014

Oct. 9, 2014

The first draft of the Allocation Token EPP Extension ( http://tools.ietf.org/html/draft-gould-allocation-token-00 ) has been submitted to the IETF. I co-authored this draft with Sharon Wodjenski and Trung Tran from Neustar to support the definition of an allocation token for allocating an object like a domain name. In one use case, the token can be used to support the releasing of reserved names via an external auction provider, where the domain names and tokens are provided to the auction provider, and the winning registrant of the auction will receive the token to pass through the registrar to the registry to allocate a domain name using a transform command like create, update, or transfer. Another use case is to use the token to authorize the allocation of domain names in a founder’s program. Other alternatives like leveraging the authinfo or leveraging one of the key, value pair extensions were considered, but we felt that having an explicit allocation token to authorize the allocation of an object was the cleanest approach. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0

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