- gtld-tech - lists.icann.org

FW: Thick Whois CL&D Policy Revision version v02.1: ready for public comment
by Francisco Arias Oct. 12, 2016

Oct. 12, 2016

FYI, There is an updated proposal to handle the RySG proposed revision to the CL&D policy to remove the requirement to implement RDAP. We are planning to put a draft updated CL&D policy for public comment before the end of the month. We are also planning to issue the request to implement RDAP (on contractual basis as opposed to policy) in parallel but separate from the request to implement the revised CL&D policy. Both requests, to implement CL&D and RDAP, are expected to happen by the end of January 2017 (after the public comment period) with effective date of implementation by 1 August 2017. Regards, -- Francisco On 10/11/16, 3:10 PM, "gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of Dennis Chang" <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of dennis.chang(a)icann.org<mailto:dennis.chang@icann.org>> wrote: Dear Thick Whois IRT Thank you for your support of the revised CL&D policy. As we discussed and agreed at the meeting today, attached is the final version we will post for Public Comment. ICANN will now initiate the process to publish the draft policy for public comment. When published, I’ll send a note to the IRT. As for the Transition policy, I’ll be sending out a separate email to you. Thanks Dennis Chang From: <gnso-impl-thickwhois-rt-bounces(a)icann.org> on behalf of Dennis Chang <dennis.chang(a)icann.org> Date: Monday, October 10, 2016 at 2:42 PM To: Roger D Carney <rcarney(a)godaddy.com>, "gnso-impl-thickwhois-rt(a)icann.org" <gnso-impl-thickwhois-rt(a)icann.org> Subject: Re: [Gnso-impl-thickwhois-rt] FW: Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Thanks Roger for your support. At our last meeting, we heard from Marc, Joyce and Ray of their support also. Steve replied with his support today and Marc had already provided his support via email. So I have the following list of IRT members’ support so far. Marc Anderson Theo Geurts Steve Metalitz Joyce Lin Ray Fassett Roger Carney And we’ve received NO objections. Could we hear from other IRT members not on the list so far? Thanks Dennis Chang From: <gnso-impl-thickwhois-rt-bounces(a)icann.org> on behalf of Roger D Carney <rcarney(a)godaddy.com> Date: Monday, October 10, 2016 at 1:35 PM To: "gnso-impl-thickwhois-rt(a)icann.org" <gnso-impl-thickwhois-rt(a)icann.org> Subject: Re: [Gnso-impl-thickwhois-rt] FW: Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Good Afternoon, Thanks Dennis, as stated on the call we do support this updated version of the CL&D policy. Thanks Roger From: gnso-impl-thickwhois-rt-bounces(a)icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] On Behalf Of Dennis Chang Sent: Sunday, October 09, 2016 9:12 PM To: gnso-impl-thickwhois-rt(a)icann.org Subject: [Gnso-impl-thickwhois-rt] FW: Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dear IRT Members, Thanks for your review and support of this policy revision process. To the initial plan that we shared with you on 21 September 2015, we are proposing one change. Public comment. Upon further consideration, we’ve decided to put the revision of the CL&D policy document out for a public comment. Although, the change to the policy language is simple and it does not change the intended implementation, we felt that a public comment would best support the transparency of the process. It’s our goal to secure the support of the IRT for this plan by our next meeting on 11 October 2016 and proceed with the public comment. Please review the attached revised policy and provide your comment prior to the meeting if possible. Thanks Dennis Chang From: <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org>> on behalf of Dennis Chang <dennis.chang(a)icann.org<mailto:dennis.chang@icann.org>> Date: Wednesday, September 21, 2016 at 10:41 AM To: "gnso-impl-thickwhois-rt(a)icann.org<mailto:gnso-impl-thickwhois-rt@icann.org>" <gnso-impl-thickwhois-rt(a)icann.org<mailto:gnso-impl-thickwhois-rt@icann.org>> Subject: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: · The consistent labeling and display of WHOIS output for all gTLDs · The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration<https://www.icann.org/resources/pages/reconsideration-16-10-rysg-request-20…> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars<https://www.icann.org/rdap-gtld-profile>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org<http://www.icann.org> "One World, One Internet"

2 1

FW: Proposal to remove RDAP from the Thick Whois CL&D Policy (was Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration)
by Francisco Arias Sept. 21, 2016

Sept. 21, 2016

FYI, On 9/21/16, 10:41 AM, "gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of Dennis Chang" <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of dennis.chang(a)icann.org<mailto:dennis.chang@icann.org>> wrote: Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: * The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration<https://www.icann.org/resources/pages/reconsideration-16-10-rysg-request-20…> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars<https://www.icann.org/rdap-gtld-profile>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list (gnso-impl-thickwhois-rt(a)icann.org) Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org "One World, One Internet"

1 0

Delegated nameservers RFC compliance
by Mark Andrews Sept. 1, 2016

Sept. 1, 2016

As part of preparations for shipping nameservers that support DNS COOKIES (RFC 7873) I have been measuring EDNS Compliance in a number data sets the results of which are available at https://ednscomp.isc.org along with a online tester. We wanted how much will break when we ship BIND 9.11.0 which has DNS COOKIES on by default. We found there were zones that could no longer resolve if validation was enabled. Named falls back to plain DNS on certain detected errors as there isn't time to probe exact failure causes by trial and error. Even if trial and error worked for DNS COOKIEs the problem will get worse as more EDNS features get used. We found zones that were taking multiple seconds to resolve. We were back to the sort of resolution times we saw when EDNS was first introduced for some zones. We saw increased queries being needed to be made as servers didn't correctly ignore unknown EDNS options. All these errors are easily determinable by running a handful of queries against each server. RFC 1034 and RFC 1035 were written assuming that servers delegated to would be RFC compliant. Currently GTLD servers are checked and there is no reason that servers delegated to by the GTLD servers can't also be checked and the operators asked to fix the faults detected. This can be done at both the RFC 1034 and RFC 1035 level and at the EDNS level. It is not a actionable condition if all the EDNS tests fail in a way that indicated the EDNS is not supported. I would suggest that {E}DNS compliance checking be done within a week of a new server being registered and delegated to and 1/2 yearly thereafter. If a server fails a test that the operator / registrant be informed and the server be retested in a month. I would also suggest that compliance testing results and test date should be record in whois or similar so there is no need to retest too frequently. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

3 5

RDAP referral to registrar ?
by Pascal Bouchareine Sept. 1, 2016

Sept. 1, 2016

Hello, Francisco already replied to me here - the question was: // Is there going to be a guarantee that one will be able to perform a domain RDAP lookup up to the registrar RDAP service ? Section 2.3 of the RDAP operational profile does not seem to enforce a link to the registrar RDAP server for other cases than thin registries. // >From an automation and information publishing perspective, we think always having a link to registrar from the registries might be very convenient. Is there a way to publish this whenever it's available ? (the use case we're working on was https://github.com/Gandi/dnsknife/bl ob/master/docs/extending_registrar_functions.txt) Or is this a small enough constraint that can be relaxed later and doesn't need inclusion in the operational guidelines right now ? Or maybe I'm just misunderstanding the implementation goals- if so sorry about that. Thank you!

7 9

Call for Participation ICANN 55 Marrakesh
by Dr Eberhard W Lisse Aug. 30, 2016

Aug. 30, 2016

Call for Participation TechDay at ICANN 55 in Marrakesh, Morocco The ICANN Tech Working Group is again planning a technical workshop at the ICANN 55 meeting on 07 March 2016 in Marrakesh, Morocco. The TechDay Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss technical topics related to registry and DNS work and security. For reference, the most recent session was held at the ICANN meeting in Dublin, Ireland on 19 October 2015. The presentations and transcripts are available at: https://meetings.icann.org/en/dublin54/schedule/mon-tech. We are specially interested in: 1. Registration information accuracy panel For this panel, we are interested in presentations relating to registry contact data cleanup, address validation, malicious registration data verification, batch and/or real-time validation. We would like, in particular, to see solutions leveraging Open Source, Open Data or Open Research in order to make them available to a wider audience. 2. Next Generation DNS Infrastructure Panel: For this panel we are seeking presentations from next generation DNS infrastructure platform implementers. We are looking presentation on DNS Anycast platform that are small footprint, low cost, highly performant and scalable. We are particularly interested in presentations on DNS infrastructure that use an innovative approach to deliver new breakthroughs in either footprint, cost, performance or scalability. We are interested in understanding how provisioning is performed, detailed hardware and software routing architecture, logging, monitoring, packet capture, multi-tenancy, performance metrics. 3. In addition, we welcome suggestions for additional topics, such as; * Registry, EPP, RDAP initiatives * Big Data & associated data analysis * IETF DNS protocol updates * Registry security 4. And, as usual we shall invite a host presentation. If you are interested in participating, please email one or all of el(a)lisse.NA ondrej.filip(a)nic.cz jacques.latour(a)cira.ca kimberly.carlson(a)icann.org preferably by 2016-01-17. We hope that you can join us and request that you disseminate this Request to other lists where it might of of interest. el

5 8

"last update of RDAP database"
by Brian Mountford Aug. 19, 2016

Aug. 19, 2016

ICANN RDAP tech folks, I wanted to comment on an aspect of the ICANN operational profile. 1.4.12, 1.4.13 and 1.5.14 indicate that domains, nameservers and entities should include an event with type "last update of RDAP database". It sounds like you are assuming that the database will have a timestamp as of which all data are consistent, like a snapshot. Modern distributed databases don't necessarily have such a timestamp. If the database is "eventually consistent" (see https://en.wikipedia.org/wiki/Eventual_consistency) updates to a particular object may not show up in database reads until some time later. Technically, the only guarantee is that the new, updated value will show up eventually. So when we return a "last update time", that doesn't mean that the data being returned in the RDAP response is as fresh as what was written on or before the last update time. The read may lag behind the update. I am going to go ahead and set the last update time to the current time, because that's when the most recent update could have occurred. But that will not mean that the returned data is current as of that time, because such a guarantee is impossible in an eventually consistent database. Thanks. Brian

2 1

gTLD RDAP profile - release candidate 2
by Francisco Arias Aug. 18, 2016

Aug. 18, 2016

Dear colleagues, I’ve attached release candidate 2 (i.e., draft final 2) of the gTLD RDAP profile in Office Open XML format. This version is a redline vs release candidate 1 (last version shared here on 30-June). We plan to publish the final version by early next week. Leaving aside minor wording and format edits, the main changes are as follows: 1. Section III: added reference to the upcoming Consistent Labeling and Display policy. 2. Section 1.5.17: clarified that registrars only need to show the variant names they know about. 3. Section 3.1.1: clarified footnote regarding expected requirement for registrations under .com, .jobs, and .net. Regards, -- Francisco

3 3

just a message
by paf Aug. 18, 2016

Aug. 18, 2016

Hi friend! You were looking for some info, remember? I think I've got it, check it out <http://biquislare.myrummy.com/e4qqaie> Sent from a prehistoric stone tablet, paf

1 0

Test tool for the RDAP and CL&D changes to WHOIS?
by Alexander Mayrhofer Aug. 10, 2016

Aug. 10, 2016

Hello Gustavo, Will there be a test tool for RDAP and WHOIS updates required by CL&D, like it was provided for the WHOIS clarifications? If yes, is there a rough time scale by when such a tool would be available? Best, Alex

2 1

RDAP question
by Brian Mountford Aug. 9, 2016

Aug. 9, 2016

Another RDAP question as it applies to the operational profile. *RFC 7483 4.3. Notices and Remarks* While the "remarks" array will appear in many object classes in a response, the "notices" array appears only in the topmost object of a response. For domain, nameserver and entity search results, should boilerplate remarks required by the operational profile appear in each constituent object, or at the top level? Thanks. Brian Mountford Google Registry

2 4