- gtld-tech - lists.icann.org

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

Re: [gtld-tech] RDAP requirement for registrars sponsoring "thick" gTLDs only?
by Roger D Carney Aug. 8, 2016

Aug. 8, 2016

Good Afternoon, Thomas, your interpretation is correct, that is the intent of the wording in section 3.1.1: Registrars are not required to have RDAP server services if all their gTLD registrations are thick registrations (Registrars are still required to provide WHOIS lookups for com/net/jobs via port-43 and this implementation will be redefined/honed by the Thick WHOIS IRT). Thanks Roger -----Original Message----- From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Thomas Corte Sent: Wednesday, August 03, 2016 8:16 AM To: gtld-tech(a)icann.org Subject: [gtld-tech] RDAP requirement for registrars sponsoring "thick" gTLDs only? Hello Francisco, On 22/07/2016 02:00, Francisco Arias wrote: > 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: > 3. Section 3.1.1: clarified footnote regarding expected requirement for registrations under .com, .jobs, and .net. I've got a question regarding this section, as it is currently published at https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en: It says: "3.1.1. For all gTLDs, with the exception of .com, .jobs and .net, Registrars are REQUIRED to provide an RDAP service for domain names for which the Registrar is the Sponsoring Registrar, and the registration data stored in the Registry is "thin". Registrars MAY offer an RDAP service for domain names registered under any gTLD." So, if a registrar *exclusively* sponsors domains in gTLDs with "thick" registries (and, possibly, also offers .com, .jobs and .net domains), does this effectively mean that there is *no* requirement to operate a registrar RDAP server at all? Correct me if I'm wrong or if this is not the intended interpretation, yet it would actually make a lot of sense to lift the RDDS operation requirements for registrars in this fashion, given that they have little to add to the information already available from a thick registry's RDDS systems. Best regards, Thomas Corte -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: Thomas.Corte(a)knipp.de<mailto:Thomas.Corte@knipp.de> Germany

2 1