- gtld-tech - lists.icann.org

Re: [gtld-tech] Whether registrars have to implement a RDAP service
by Michele Neylon - Blacknight Dec. 9, 2015

Dec. 9, 2015

Why on earth would we go the expense of implementing this if it’s: - temporary - we can’t use proper ACLs etc., due to gaps in the ICANN policy -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 07/12/2015, 9:42 p.m., "gtld-tech-bounces(a)icann.org on behalf of Roger D Carney" <gtld-tech-bounces(a)icann.org on behalf of rcarney(a)godaddy.com> wrote: >Good Afternoon, > >Thanks Francisco for providing some great context around each of these updates. > >I believe the wording in 3.1.1 will cause some confusion with the intent of this update in 2.3, with 3.1.1 stating all sponsored names whereas the intent being only thin sponsored names. > >Additionally, I would like to confirm that according to the wording in this latest draft, ICANN is suggesting that all Registrars sponsoring names in any thin registry will be obligated to create and manage code and infrastructure for a temporary RDAP server implementation that will be rendered useless and most likely be discarded once the three remaining thin TLDs are moved to thick? > > >Thanks >Roger > > >-----Original Message----- >From: gtld-tech-bounces(a)icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias >Sent: Friday, December 04, 2015 4:57 PM >To: gtld-tech(a)icann.org >Subject: [gtld-tech] Whether registrars have to implement a RDAP service > >Dear colleagues, > >Regarding open issue I.3 Whether registrars have to implement a RDAP service. > >In section 2.3 of v12 we say that registrars MUST offer RDAP service for all "thin registrations” that they sponsor. There appears to be no benefit in requiring registrars to offer RDAP service for a thick registration. >Please note that the requirements is regarding individual registrations as opposed to TLD-wise. We included a definition for “thin registration”. > >Regards, > >-- >Francisco. >

3 2

Whether registrars have to implement a RDAP service
by Francisco Arias Dec. 7, 2015

Dec. 7, 2015

Dear colleagues, Regarding open issue I.3 Whether registrars have to implement a RDAP service. In section 2.3 of v12 we say that registrars MUST offer RDAP service for all "thin registrations” that they sponsor. There appears to be no benefit in requiring registrars to offer RDAP service for a thick registration. Please note that the requirements is regarding individual registrations as opposed to TLD-wise. We included a definition for “thin registration”. Regards, -- Francisco.

2 1

Allowing/requiring differentiated access
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding open issue I.4 Whether to require implementation of differentiated access in RDAP for gTLD Registries. In section 1.4.11 of v12 the profile allows those that have a contract provision or once there is a consensus policy to offer differentiated access. The Registry Agreement for new gTLDs and the 2013 Registrar Accreditation Agreement are clear about not allowing differentiated access when they say about the Registration Data Directory Services (a.k.a. Whois) output: "The fields specified below set forth the minimum output requirements." or "The format of responses shall contain all the elements and follow a semi-free text format outline below.” For the three legacy gTLDs that have differentiated access in their registry agreements, there are, at least two models. One model describes two levels of access (similar to Andrew's proposal shared in this list) for .tel and .cat. Another model includes four levels of access for .name. Additionally, there is a Policy Development Process (PDP) initiating on Registry Directory Services (http://gnso.icann.org/en/council/resolutions#201511) that will consider the broader issue of access to registration data, including the potential for differentiated access as described in the adopted Charter for the PDP working group (see Annex C of the Final Issues Report at https://whois.icann.org/sites/default/files/files/final-issue-report-next-g eneration-rds-07oct15-en.pdf). Given the ongoing discussions and work in the community on differentiated access, it is premature to include a requirement for all gTLDs in the RDAP Profile. For parties interested in differentiated access, we’d recommend to participate in the upcoming Registry Directory Services PDP, where a call for volunteers is expected to go out next January. I plan to forward the call for volunteers to this list when I see it. Regards, -- Francisco.

1 0

Searchabilty in the gTLD RDAP profile
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding pending issue P.3. Francisco to check if ICANN would be able to require implementation of the Boolean search capabilities using existing contractual mechanism. In v12 we removed the requirement for searchability altogether. The new gTLD registry agreement (section 1.10.1) requires searchable Whois on the web-based Whois service. With that in mind we reconsidered having any searchability requirements in the profile. Those registries that have searchable Whois provisions in their agreement, should continue to offer it in their web-based RDDS (i.e., HTMTL user friendly interface) with no requirement to offer it in RDAP. Your input is welcome. Regards, -- Francisco.

1 0

Timeline for registrars to provide their expiration date to registries
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding pending issue P.2. Francisco to check on the timeline of the requirement for registrars to provide the registrar expiration date to registries. This is addressed in the draft Thick Whois Policy that went for public comment in parallel with the draft RDAP profile. In short registrars will be required to provide this data field and registries to show it once there is an EPP extension addressing this. Regards, -- Francisco.

1 0

Whether to include requirements from the T&T policy recommendations
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding pending issue P.1. Francisco to check if we can already include the requirements from the Translation & Transliteration PDP in the profile. In v12 we did not include requirements from the Translation & Transliteration policy recommendations. T&T requirements could be added to the next release of the profile in the future. It seems too early in the policy implementation to add it to the profile (the policy recommendation was only published a few weeks ago). We should leave the policy implementation process to follow its process. Regards, -- Francisco.

1 0

What should registrars respond for non-sponsored names
by Francisco Arias Dec. 4, 2015

Dec. 4, 2015

Dear colleagues, Regarding open issue 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 in v06) in the gTLD RDAP profile. In section 3.1.2 of v12 we left the MUST for registrars to return an HTTP 404 for names they don’t sponsor. Registries are the authorative source of information, if a Registry says that a registrar is the sponsoring registrar, but the registrar is not sponsoring the domain, something is broken. HTTP 404 seems the most accurate way to indicate this. It is true that RDAP uses HTTP, which requires support for loop detection, however the registries do not redirect, they provide a link member as defined in the profile, therefore, the built-in HTTP loop detection mechanism might not work if the registrar offers a redirection to the registry. In any case, we are deferring changing the current draft requirements until/if there is consensus from the community to do so. Your input is welcome. Regards, -- Francisco.

1 0

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