- gtld-tech - lists.icann.org

Requirements for the CA in TLS and DANE
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding open issue I.1 What requirements should be for the CA to be used in TLS or whether to use DANE in the gTLD RDAP profile In sections 1.3.3 and 1.3.4 of v12 we added a MUST for DANE support and kept the MUST for CA requirements (already in v06 of the draft). Since RDAP would be a new service it would seem ok to have requirements for not-widely implemented technologies like DANE. RDAP and DANE could grow in adoption together as RDAP is deployed. We left the MUST for the CA requirements given the current reality of support. In the future, we could consider removing the CA requirements once that support for DANE is observed in sufficient scale in RDAP. Regarding the potential issue of certain jurisdiction requiring the use of a CA that would not comply with the requirements set forth in the profile, we considered that we already have a process to address cases where a contracted party indicates that it is legally prevented by local/national laws from complying with ICANN's requirements regarding the collection, display and distribution of registration data. Such process could be used in such case to seek a waiver to the requirement. Please note that v12 in public comment is just a draft and your input is welcome. Regards, -- Francisco.

1 0

Draft gTLD RDAP profile in public comment
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, I wanted to let you know that the draft gTLD RDAP profile is now in public comment at https://www.icann.org/public-comments/rdap-profile-2015-12-03-en Your input would be more than welcome. If you like to discuss in this list, we will also take input received here into consideration. The public comment period ends at 23:59 on 18-Jan-2016 UTC. The version that is for public comment takes into consideration the input that we received from you in the list and during the in-person discussions. Thank you for that. As you may remember there were a few open items from those discussions, I’ll send a separate emails to explain what we did regarding those in the current draft. In case it is of any help, I’ve attached a Word redline of the version we published for public comment (v12) vs the version we shared in the list in September (v06). Regards, -- Francisco.

1 0

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

Re: [gtld-tech] gtld-tech Digest, Vol 30, Issue 23
by Brian Mountford Oct. 30, 2015

Oct. 30, 2015

And is weirds(a)ietf.org a list I would need to join somehow, akin to this list? Or do I just send a message? On Fri, Oct 30, 2015 at 8:00 AM, <gtld-tech-request(a)icann.org> wrote: > Send gtld-tech mailing list submissions to > gtld-tech(a)icann.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/gtld-tech > 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. RDAP Questions (Brian Mountford) > 2. Re: RDAP Questions (Andrew Sullivan) > 3. Re: [weirds] gTLD RDAP profile meeting during IETF94 > (Francisco Arias) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Oct 2015 17:49:12 -0400 > From: Brian Mountford <mountford(a)google.com> > To: gtld-tech(a)icann.org > Subject: [gtld-tech] RDAP Questions > Message-ID: > <CALRmJyhCro= > HEU11DsQxzaZAJn30uJt5wjM_q2hJT58w2+KdXg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Is this a forum for questions about RDAP specifically (as opposed to the > ICANN profile regarding RDAP)? Or should I direct those questions > elsewhere? Thanks. > > Brian >

2 1

RDAP Questions
by Brian Mountford Oct. 29, 2015

Oct. 29, 2015

Is this a forum for questions about RDAP specifically (as opposed to the ICANN profile regarding RDAP)? Or should I direct those questions elsewhere? Thanks. Brian

2 1

RDAP Policy Questions
by Brian Mountford Oct. 27, 2015

Oct. 27, 2015

Hello all. I have some questions about the ICANN policy document, directives 1.5.16 and 2.1. I couldn't find existing answers in the archive of this list, so I thought I would ask. As a general matter, should I also ask my RDAP-only questions here (as opposed to the issues specifically related to ICANN policy)? Or is there another forum for such questions? Brian -------------------------------------------------- *1.5.16. Entities MUST use jCard [RFC7095] structured addresses.* RFC 7095 defines two different types of structured address: one with the street address lines concatenated into one string, and one with a subarray for the street address. It says: 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 the first version (list of simple strings, with the street lines concatenated), what is to be done with addresses containing more than two street address lines? -------------------------------------------------- *2.1. Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published.* Domain and entity searches are specifically mentioned, but nameserver searches are not. Does that mean that registries need not support nameserver search? Or was that an oversight? RFC 7482 does not cover entity search by address, only by name or handle. Is ICANN requiring support for an additional way to search for entities? What would the syntax of such a search be?

3 5

2nd Call for Presentations for TechDay at ICANN Dublin
by Dr Eberhard W Lisse Oct. 16, 2015

Oct. 16, 2015

We have space for one more 20 minute presentation at Tech Day in Dublin. 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 greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 4

gTLD RDAP profile meeting during IETF94
by Gustavo Lozano Oct. 16, 2015

Oct. 16, 2015

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

6 5