November 2015 - gtld-tech - lists.icann.org

Draft RDAP Operational Profile for gTLD Registries and Registrars
by Francisco Arias Jan. 16, 2016

Jan. 16, 2016

Dear colleagues, As you may know, most gTLD registries and registrars have a provision in their respective agreements to implement RDAP. However, before requesting RDAP implementation, we would like your thoughts and inputs on which features, basic parameters, and objects will need to be implemented. We are calling this document the RDAP Operational Profile for gTLD Registries and Registrars. Attached you will find the first draft of the RDAP Operational Profile for gTLD Registries and Registrars (in Word and PDF formats). We are planning a session on the subject during both the ICANN meeting in Dublin and the IETF in Yokohama. Your feedback on this early document would be greatly appreciated by 9 November 2015. By then, we expect to have an updated document that we plan to publish for public comment around mid November. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

10 25

gTLD RDAP Profile discussion at Yokohama
by Francisco Arias Nov. 4, 2015

Nov. 4, 2015

Colleagues, I’ve attached the slides from today’s (4-Nov) session on the gTLD RDAP profile. Thank you all of you that attended either in person or remotely. Please see below my notes and let me know if I missed or misrepresented something. We agreed to: A.1 Change 1.3.2 to have HTTPS as a MUST and as requirement in the bootstraping, but allow HTTP as optional A.2 Clarify requirement in 2.8.3 re: bootstrapping and 1.3.6 re: requirement for IPv4 and IPv6 transport A.3 Change 1.4.1 to allow queries with mixed A-label and U-label IDNs A.4 Remove requirements in 1.4.4 and 1.4.5 about blank spaces and newlines A.5 Keep the requirement in 2.8.2 regarding caching or issue re: change of the bootstrapping entry A.6 Keep requirement in 1.3.4 to register RDAP extensions before using them A.7 Keep requirement in 1.4.3 to maintain the case of the data as received in EPP A.8 Keep the "last update DB" item described in 1.4.12 as a new event type A.9 Keep the requirement in 1.5.2 to include U-label format of IDN in response A.10 Fix requirements regarding thin registry's for fields to be included in 1.5.8 and through the profile A.11 Keep the requirement in 1.5.14 to show the registrar expiration date A.12 Clarify language in 1.5.17 regarding requirement to show only allocated variants A.13 Keep requirement in section 1.5.18 to use a remarks member with title "EPP Status Codes" A.14 Clarify requirement in 1.5.19 regarding the secureDNS member to be shown if stored by the registry or registrar A.15 Remove the requirement for Boolean search capabilitiesout until there is an RFC. Once there is an RFC, ICANN should be able to require implementation using existing contractual mechanism (Francisco to confirm) A.16 The behavior for responses for multiple host objects (section 2.3) should be specified in a RDAP extension A.17 Keep the re:related mechanism in section 2.4 for the registry to refer to the registrar (no need to specify it in a RDAP extension) A.18 Clarify text in 2.9.1 as requested A.19 Have the EPP status "ok" mapped to "active" in the profile We have the following open issues: I.1 What requirements should be for the CA to be used in TLS or whether to use DANE I.2 Whether registrars that are queried for a name they don't sponsor should respond with HTTP 404 as a MUST or have the option to redirect (section 3.1.2) I.3 Whether registrars have to implement a RDAP service I.4 Whether to require implementation of differentiated access in RDAP for registries Other pending issues: P.1. Francisco to check if we can already include the requirements from the Translation & Transliteration PDP in the profile P.2. Francisco to check on the timeline of the requirement for registrars to provide the registrar expiration date to registries P.3. Francisco to check if ICANN would be able to require implementation of the Boolean search capabilities using existing contractual mechanism Regards, -- Francisco.

1 0

RDAP Port 43 Value
by Brian Mountford Nov. 3, 2015

Nov. 3, 2015

RFC 7483, section 4.7 talks about the port43 member, which is supposed to name the WHOIS server where the object can be found. As a registry, are we supposed to set this value to our WHOIS server, or to the registrar's? The WHOIS protocol has a similar field, which is supposed to be the registrar's server. But that takes the form of a URL, whereas RDAP port43 is explicitly not a URL. So I'm not sure what we are to put in the field, and I couldn't find any directives in the profile document. Thanks. Brian

1 0

Re: [gtld-tech] [weirds] gTLD RDAP profile meeting during IETF94
by Francisco Arias Nov. 3, 2015

Nov. 3, 2015

Dear colleagues, We have room 419 in the IETF venue from 9:00 - 12:00 on Wednesday, 4-Nov (local time). Anyone interested in discussing the draft gTLD RDAP profile is welcome. Feel free to circulate this. Regards, -- Francisco. On 10/14/15, 5:18 PM, "weirds on behalf of Gustavo Lozano" <weirds-bounces(a)ietf.org<mailto:weirds-bounces@ietf.org> on behalf of gustavo.lozano(a)icann.org<mailto:gustavo.lozano@icann.org>> wrote: Hello, [Apologies if you receive multiple copies of this email] Are you interested in meeting during IETF94 in order to discuss the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html)? If there is enough interest, I could request a room. Remote participation would be provided if there is interest. Regards, Gustavo

1 1