- gtld-tech - lists.icann.org

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

RDAP Bootstrap Mechanism for EPP Repository Identifiers?
by Klaus Malorny Aug. 3, 2016

Aug. 3, 2016

Hi, I just wondered whether an RDAP Bootstrap Service Registry is planned for EPP Repository Identifiers[1], i.e. for ROID suffixes, similar to the Bootstrap Service Registry for Domain Name Space[2] – or, if more appropriate, a generalized approach to include entities from address registries as well. This would allow RDAP clients to look up a given entity handle without prior knowledge to which registry it belongs. Or do I miss existing functionality? Regards, Klaus [1] https://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xhtml [2] http://www.iana.org/assignments/rdap-dns/rdap-dns.xhtml

3 4

FW: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017
by Gustavo Lozano Aug. 1, 2016

Aug. 1, 2016

Hello Colleagues, I think that you may find this news alert of your interest. Regards, Gustavo From: ICANN News Alert <no-reply(a)external.icann.org> Reply-To: "no-reply(a)external.icann.org" <no-reply(a)external.icann.org> Date: Tuesday, July 26, 2016 at 17:34 To: Gustavo Lozano <gustavo.lozano(a)icann.org> Subject: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017 > ICANN News Alert > <http://www.icann.org/> > News Alert > https://www.icann.org/news/announcement-2016-07-26-en > > New Registration Data Directory Services Requirements for gTLD Registries, > Registrars to Take Effect in February 2017 > 26 July 2016 > > ICANN today announced that gTLD contracted parties must update their > Registration Data Directory Services (RDDS) by 1 February 2017. Registries and > registrars are required to implement the new Registration Data Access Protocol > (RDAP) gTLD Profile <https://www.icann.org/rdap-gtld-profile> . Registries > must also implement the data specifications defined in the Registry > Registration Data Directory Services Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> . > > The RDAP gTLD Profile and the RDDS Consistent Labeling and Display Policy are > the products of community efforts to improve the current system used to > discover who controls a domain name. This system comprises data retrieval > protocols WHOIS and a web-based version of WHOIS and databases controlled > by registries and registrars that contain domain registration information. > > ICANN has notified contracted parties that they are responsible for modifying > their systems within six months. ICANN consulted these parties when defining > the new requirements and implementation plans. > Background > The Registration Data Access Protocol was developed by the Internet > Engineering Task Force <https://ietf.org/> to eventually replace the WHOIS > protocol. This new protocol is superior to WHOIS in terms of data access > security, support for international characters, extensibility, and in the > standardization of query, response and error messages. The RDAP gTLD Profile > maps ICANN policy and contractual requirements onto technical requirements in > order to standardize directory services across gTLD contracted parties. > > The RDDS Consistent Labeling and Display Policy is a Consensus Policy > developed and adopted in accordance with ICANN Bylaws. The policy is the > result of recommendations adopted by the GNSO Council after the completion of > the Thick WHOIS Policy Development Process. The ICANN board adopted these > recommendations on 7 February 2014. > > The goal of the RDDS Consistent Labeling and Display Policy is to align the > way registries and registrars label and display registration data outputs. The > policy uses the output specifications found in the 2013 Registrar > Accreditation Agreement as the standard, thus only registries need to update > their systems. Changes might include renaming or re-ordering fields and > displaying additional data, such as registrar abuse contact information. > > For more information on these topics, visit: > * Registration Data Access Protocol gTLD Profile > <https://www.icann.org/rdap-gtld-profile> > * Registry RDDS Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> > * Thick WHOIS Policy Implementation > <https://www.icann.org/resources/pages/thick-whois-2016-06-27-en> > * Policy Implementation at ICANN <https://www.icann.org/policy/implementation> > About ICANN > ICANN's mission is to help ensure a stable, secure and unified global > Internet. To reach another person on the Internet, you have to type an address > into your computer - a name or a number. That address has to be unique so > computers know where to find each other. ICANN helps coordinate and support > these unique identifiers across the world. ICANN was formed in 1998 as a > not-for-profit public-benefit corporation and a community with participants > from all over the world. ICANN and its community help keep the Internet > secure, stable and interoperable. It also promotes competition and develops > policy for the top-level of the Internet's naming system and facilitates the > use of other unique Internet identifiers. For more information please visit: > www.icann.org <https://www.icann.org/> . > > > This message was sent to gustavo.lozano(a)icann.org from: ICANN News Alert | > no-reply(a)external.icann.org | ICANN | 12025 Waterfront Drive Suite 300 | Los > Angeles, CA 90094-2536 Email Marketing by > <http://www.icontact.com/a.pl/144186> > Manage Your Subscription > <http://app.icontact.com/icp/mmail-mprofile.pl?r=23976128&l=6333&s=2VAT&m=99… > 78&c=165637>

2 1

number of characters in a domain?
by Ryan Finnesey July 23, 2016

July 23, 2016

I was hoping someone can help me confirm my research. I am correct that domains are now limited to 67 characters in length including the extension? Cheers Ryan

3 2

Re: [gtld-tech] gtld-tech Digest, Vol 39, Issue 5
by Brian Mountford July 23, 2016

July 23, 2016

Francisco, I have questions about sections 1.5.14, 1.5.16 and 2.8.2. Profile Directive 1.5.14. The domain object in the RDAP response MUST contain the following events: - An event of eventAction type registration. - An event of eventAction type expiration. - An event of eventAction type last changed. The event of eventAction type last changed MUST be omitted if the domain name has not been updated since it was created. - An event of eventAction type last update of RDAP database. Is any particular ordering preferred in the results? Expiration will probably be later than last changed and last update. Should it come before or after the last changed and last update? Profile Directive 1.5.16. Entities MUST use jCard [RFC7095] structured addresses. RFC 7095 defines two different types of structured address: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If it is the first version (list of simple strings), what is to be done with addresses containing more than two street address lines? Profile Directive 2.8.2. Registrar object lookup using an entity search on the fn element MUST be supported. RFC 7482 3.2.3. says: XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1 of [RFC7483]. This is straightforward enough when referring to contacts and registrants, but I am not sure how it applies to registrars. Our database stores registrars, which have a name, and also registrar contacts, which hang off registrars, and themselves also have names. Are you asking us to search by registrar name (which we would prefer), or by registrar contact name? Thanks. Brian

2 3

Do not implement before date in CL&D and RDAP profile
by Francisco Arias July 21, 2016

July 21, 2016

Dear colleagues, As you may recall the gTLD RDAP profile and Thick Whois policy implementation – Consistent Labeling and Display (CL&D for short) are synchronized and have a proposed effective date of 1 February 2017. This means enforcement would start on that date. However, in monitoring compliance with a given policy or contractual requirement we also need time to develop our tools and be able to *not* report false compliance issues (e.g., our current tool would raise an issue if it encounters the new Whois output that is specified in CL&D). We need to update that tool to avoid that issue from happening. We’d like to add to both CL&D and the RDAP profile a “do not implement before” date to avoid the aforementioned issue. We are thinking we are going to need approximately four months to update/build our tools be able to identify the updated Whois output and RDAP output. That would give contracted parties approximately a two-month window for release before the effective. We are planning to add such a date to the documents, unless there is a reason why people think we should not. Regards, -- Francisco

6 9

gTLD RDAP profile - release candidate
by Francisco Arias June 30, 2016

June 30, 2016

Dear colleagues, I’ve attached release candidate 1 (i.e., draft final) of the gTLD RDAP profile in PDF and Office Open XML formats. This version is a redline vs the version that underwent public comment. We plan to publish the final version by the end of July. Please review and let us know if you find any glaring issues by 15 July. This version incorporates the feedback received during the public comment period we run earlier this year and this mailing list. The main changes are as follows: 1. Section 1.3.6: allow contracted parties to add fields, events, roles without further ICANN approval. 2. Section 1.4.1: clarify requirement to support queries for strings mixing A- and U-labels. 3. Section 1.5.6: clarify mapping of EPP to RDAP statuses. 4. Section 1.5.15: make registrar expiration date optional. 5. Section 1.5.23: allow contracted parties to operate RDAP test services. 6. Section 3.1.1: limit requirement for registrars to offer RDAP services for thin registrations only. 7. Section 3.1.1: clarify that registrars will only be required to offer RDAP services for thin registrations under .com, .jobs, and .net until the effective date of the Thick Whois policy. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN PGP fingerprint: 1FDE 819F 7BEC 1CB2 127E EE54 9A4D 337B D510 E397

1 0

FW: Draft Consistent Labeling & Display - Revised Policy Language
by Francisco Arias June 29, 2016

June 29, 2016

FYI On 6/29/16, 6:42 PM, "gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of Fabien Betremieux" <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of fabien.betremieux(a)icann.org<mailto:fabien.betremieux@icann.org>> wrote: Dear IRT members, As discussed in our meeting earlier today, we have posted our revision of the Policy language for implementation of the Consistent Labeling and Display requirement on our wiki: https://community.icann.org/pages/editpage.action?pageId=52889541. It is also attached to this email for your convenience. Please note that the format of the policy, after our revision, is different from the draft we posted for public comments in December (https://www.icann.org/public-comments/rdds-output-2015-12-03-en) We believe this was necessary to address the feedback we received from the community and the IRT in terms of the linkage of the Policy with Specification 3 of the 2013 RRA and the Whois Clarifications Advisory. For instance, while the draft policy required "The labeling and display of all gTLD registries web-based RDDS output , must be consistent with: (a) Specification 3 of the 2013 Registrar Accreditation Agreement (RAA)”, the revised policy lists specific requirements such as “3. If shown, the "Registrar Registration Expiration Date" field MUST appear immediately after the "Registry Expiry Date" field." Please also note that while the Policy has changed in format, it did not change in substance in order to address the community’s feedback we received in the public comment forum. Therefore, we believe this revision does not require further public comments and can be announced by 31 July 2016 for implementation with an effective date of 1 February 2017. Please review this revised Policy language as soon as possible, ideally before Friday 8 July COB. In the meantime, we will use the opportunity of our meeting in Helsinki tomorrow (http://sched.co/7Mdw) to present and discuss this revised policy language. Thank you for your consideration Best Regards -- Fabien Betremieux Sr. Registry Services & Engagement Manager Global Domains Division, ICANN US: +1 310 463 5334 | FR: +33 7 60 09 09 40 | Skype: fabien.betremieux

1 0