- gtld-tech - lists.icann.org

Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server Content
by Hollenbeck, Scott Feb. 8, 2016

Feb. 8, 2016

> -----Original Message----- > From: Francisco Arias [mailto:francisco.arias@icann.org] > Sent: Friday, February 05, 2016 3:53 PM > To: Hollenbeck, Scott; gtld-tech(a)icann.org > Subject: Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server > Content > > On 2/3/16, 9:40 AM, "gtld-tech-bounces(a)icann.org on behalf of > Hollenbeck, Scott" <gtld-tech-bounces(a)icann.org on behalf of > shollenbeck(a)verisign.com> wrote: > > > > >As I've said before, I want to deploy RDAP in a way that addresses the > issues we have with WHOIS. Functional equivalence provides no > significant benefit. > > Just to be clear, differentiated access is not the only benefit you get > from RDAP. I can think of at least the below benefits: > > 1. Internationalization support for registration data > 2. Standardized query, response, and error messages > 3. Standardized extensibility > 4. Supports private access to data (i.e., over HTTPS) > 5. Bootstrapping mechanism to easily find the authoritative server > for a given query > 6. Standardized redirection/reference mechanism (e.g., from a thin > registry to a registrar) > 7. Flexibility to support various policies All true, and not all to be realized "soon" given the multiple paths we're on. The current profile proposal says nothing about support for internationalized registration data. The bootstrapping mechanism doesn't work *at all* for entity queries. Thin-to-thick redirection won't be needed if/when thin registries become thick registries. Two of these (i18n and thick/thin) are still very much bound to ongoing policy work. As things are currently proposed we would get very little beyond benefits associated with HTTP and JSON-encoding. Scott

1 0

Verisign Labs Experimental Implementation of RDAP with Federated Authentication
by Hollenbeck, Scott Feb. 3, 2016

Feb. 3, 2016

I'd like to invite the members of this list to participate in an experiment that's focused on evaluating how well RDAP can be implemented with support for federated authentication using OpenID Connect. The details of the protocol specification and implementation approach are described in an Internet-Draft that I'm developing: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ The I-D might be a little too much detail for someone who just wants to try out the service, though. The easiest way to participate is to use a web browser pointed here: https://rdap.verisignlabs.com/ Please read the Internet-Draft if you're not interested in using a web browser. It describes the proposed protocol parameters and interactions with non-browser clients. Our web interface can be used to submit RDAP queries for domains, name servers, and entities registered in the .cc and .tv ccTLDs. The web form contains two elements: 1) a drop-down menu that allows you to select the type of object you wish to look up, and 2) the name of the object you wish to look up, such as "nic.tv" (with no quotes). You'll see two command buttons on the form. The "Don't Authenticate" button will submit an RDAP query without client authentication. The "Authenticate" button will start the process of submitting an authenticated RDAP query by prompting you to enter an OpenID identifier. We currently accept identifiers issued by Google (in the form of Gmail addresses) and Microsoft (in the form of Hotmail addresses). "Don't Authenticate" will return an RDAP response that contains very limited information to demonstrate how the amount of returned information can be controlled based on client identity and authorization. Successful client authentication using "Authenticate" will return more, but still not complete, information. We plan to add support for additional Identity Providers that will be authorized to return full information in the future as the experiment evolves. I'm especially interested in working with implementers who may be interested in setting up an Identity Provider and participating in the experiment. I've set up an email address that you can use to communicate with the development team. Please send questions and/or feedback to rdap-exp(a)verisign.com. The experiment's terms of use can be found here: https://rdap.verisignlabs.com/termsofuse The experiment will run until June 3, 2016. We will evaluate the results at that time and we will decide if the experiment will be extended or come to an end. We reserve the right to end the experiment at any time before then. Thank you, and please feel free to contact me directly with any questions. Scott

1 0

Search Engines Indexing RDAP Server Content
by Hollenbeck, Scott Feb. 3, 2016

Feb. 3, 2016

(cross-posting to multiple lists - sorry if that's inconvenient) So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one particular search engine has indexed the RDAP server of a gTLD registry operator: https://twitter.com/GavinBrown/status/692718904058191872 This is all the more reason to work on a client authentication specification that includes support for varying responses based on client identity and authorization. I've been working on such a specification and welcome feedback on the approach: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ It also begs the question of the need for a BCP describing operational practices for server operators. There are ways for web servers to influence or restrict crawler behavior, but what's appropriate in this context? Scott

7 7

FW: Registrar Expiration Date I-D
by Francisco Arias Jan. 27, 2016

Jan. 27, 2016

On 1/21/16, 11:59 AM, "Gustavo Lozano" <gustavo.lozano(a)icann.org> wrote: >Hello colleagues, > >I uploaded an I-D >(http://www.ietf.org/id/draft-lozano-ietf-eppext-registrar-expiration-date- >00.txt) in order to define an EPP extension to support the transmission of >the registrar registration expiration date from the registrar to the >registry. > >This extension is defined in order to support the ICANN Thick Whois Policy >Recommendation >(http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf) that >requires gTLD domain name registries to display the registrar registration >expiration date in the Registration Data Directory Service (e.g. Whois, >RDAP). > >Your feedback is appreciated. > >Regards, >Gustavo

19 67

Re: [gtld-tech] Registrar Expiration Date I-D
by Rob Golding Jan. 26, 2016

Jan. 26, 2016

> The problem that people claim to want to solve, however, is that > registrants are sometimes surprised at expiration because their > registrar says something's expired when the whois doesn't say that. This is already an issue for current registrants of all gtlds - when a thick registry changes the expiry date on a year after the expiry date, yet the registrant hasn't paid the registrar for the renewal :( It's usually accompanied by "but the whois says blah, so it doesn't expire until next year" > The idea is that by putting this data in the public whois, registrants > wont get surprised this way. Adding more data, especially where it could 'differ' to current data will simply be an exponential increase in registrar workload dealing with misunderstanding of whois, and benefits no-one Rob -- Rob Golding rob.golding(a)astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR * domains * hosting * vps * servers * cloud * backups *

1 0

Re: [gtld-tech] [eppext] I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt
by Rubens Kuhl Jan. 22, 2016

Jan. 22, 2016

Francisco, It's possible that Jim and Scott were looking at https://www.icann.org/resources/pages/registrars/consensus-policies-en <https://www.icann.org/resources/pages/registrars/consensus-policies-en> to find an in-force consensus policy covering such requirement. I tried finding it there as well and failed as well... that is consistent with the information that although the policy was approved by GNSO Council and the Board (https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c <https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c>) has still not come through with its IRT (Implementation Review Team), which is why the document is still in public comment and the policy is still a draft. So, perhaps the I-D is a few weeks premature and the registries opposing it might see first whether that really becomes in-force ? I also wander what happened to the reseller information relaying, which was foreseen in the policy... Rubens > Em 21 de jan de 2016, à(s) 20:51:000, Francisco Arias <francisco.arias(a)icann.org> escreveu: > > Hi Jim, > > Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-poli… <https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-poli…>, particularly section 2.1, starting on page 8. This document is in public comment at https://www.icann.org/public-comments/rdds-output-2015-12-03-en <https://www.icann.org/public-comments/rdds-output-2015-12-03-en> until 31 January. > > The draft provides a reference to the “parent” document of the aforementioned document, which is already in final form. Perhaps the reference in the draft should be to the child document? > > Regards, > > -- > Francisco > > On 1/21/16, 12:08 PM, "EppExt on behalf of Gould, James" <eppext-bounces(a)ietf.org <mailto:eppext-bounces@ietf.org> on behalf of JGould(a)verisign.com <mailto:JGould@verisign.com>> wrote: > >> Gustavo, >> >> I agree with Scott, it is not clear the relationship between the two and the relevance in the registry of maintaining this value. Can the registrar expiration date be greater then the domain expiration date, less then the domain expiration date, or completely different from the domain expiration date? The reference for the ThickWhoisPolicy is incorrect in the draft. Please provide the appropriate reference and highlight where in the Thick Whois Policy it defines the requirement for the registry to hold and display a registrar expiration date in addition to the authoritative domain expiration date. >> >> Thanks, >> >> — >> >> JG >> >> >> >> >> James Gould >> Distinguished Engineer >> jgould(a)Verisign.com <x-msg://42/jgould@Verisign.com> >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com <http://verisigninc.com/> >>> On Jan 21, 2016, at 2:52 PM, Hollenbeck, Scott <shollenbeck(a)verisign.com <mailto:shollenbeck@verisign.com>> wrote: >>> >>>> -----Original Message----- >>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org <mailto:i-d-announce-bounces@ietf.org>] On Behalf Of >>>> internet-drafts(a)ietf.org <mailto:internet-drafts@ietf.org> >>>> Sent: Thursday, January 21, 2016 2:30 PM >>>> To: i-d-announce(a)ietf.org <mailto:i-d-announce@ietf.org> >>>> Subject: I-D Action: draft-lozano-ietf-eppext-registrar-expiration- >>>> date-00.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Registrar Registration Expiration Date >>>> Extension Mapping for the Extensible Provisioning Protocol (EPP) >>>> Author : Gustavo Lozano >>>> Filename : draft-lozano-ietf-eppext-registrar-expiration- >>>> date-00.txt >>>> Pages : 15 >>>> Date : 2016-01-21 >>>> >>>> Abstract: >>>> This document describes an Extensible Provisioning Protocol (EPP) >>>> extension mapping for the provisioning and management of the >>>> registrar registration expiration date for domain names stored in a >>>> shared central repository. Specified in XML, this mapping extends >>>> the EPP domain name mapping. >>> >>> Gustavo, I wish this document would explain what this value actually means given that registrars are not the authoritative source of information for domain expiration dates. Could you please add some text to the Introduction that explains the purpose of the value and what it means of the context of the expiration date maintained by registries? Can they ever be different? What does it mean if they are different? Why are both needed if they are supposed to be the same? >>> >>> I'd also like to suggest that you add text to the different command descriptions to make it clear what the values represent when you're extending a renew, transfer, etc. >>> >>> Scott >>> >>> _______________________________________________ >>> EppExt mailing list >>> EppExt(a)ietf.org <mailto:EppExt@ietf.org> >>> https://www.ietf.org/mailman/listinfo/eppext <https://www.ietf.org/mailman/listinfo/eppext> >> > _______________________________________________ > EppExt mailing list > EppExt(a)ietf.org > https://www.ietf.org/mailman/listinfo/eppext

2 1

Re: [gtld-tech] WHOIS Data Collection Phase 2 Cycle 2 of WHOIS Accuracy Reporting System (ARS)
by Michele Neylon - Blacknight Jan. 21, 2016

Jan. 21, 2016

Russ Will this also impact thin registries ie. .com and .net, as this would have an impact on registrars? The wording of the email wasn’t very clear on this point. Regards Michele -- 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 From: <gtld-tech-bounces(a)icann.org<mailto:gtld-tech-bounces@icann.org>> on behalf of Russ Weinstein <russ.weinstein(a)icann.org<mailto:russ.weinstein@icann.org>> Date: Friday 15 January 2016 at 19:01 To: "gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>" <gtld-tech(a)icann.org<mailto:gtld-tech@icann.org>> Subject: [gtld-tech] WHOIS Data Collection Phase 2 Cycle 2 of WHOIS Accuracy Reporting System (ARS) Dear Colleagues, Between 20 January and 17 February 2016, ICANN will be initiating a large volume of WHOIS queries of gTLD registrations as part of its WHOIS Accuracy Reporting System (ARS) project utilizing the following IP addresses to perform the WHOIS queries: IP Addresses: 192.0.32.230/31 and 192.0.47.230/31 A gTLD can expect to receive query rates of 10 queries per minute; we have accounted for RSP’s with multiple gTLD’s and will attempt to limit the queries to 10 per minute across a RSP. We kindly request and appreciate your cooperation in allowing these queries to be processed and ask that you please whitelist the IP addresses provided above. As a reminder, the WHOIS ARS project was established to perform periodic studies to assess the accuracy of the contact information in the WHOIS data, with a goal of identifying opportunities to improve the accuracy of this data over time. The project was established to implement a series of improvements recommended by the WHOIS Review Team and approved by the Board (8 November 2012) on the manner in which ICANN carries out its responsibilities regarding WHOIS. This collection of data will support the next cycle in the WHOIS ARS, Phase 2 Cycle 2, which aims to assess syntax and operability accuracy of the contact information in a gTLD WHOIS record. Accuracy will be determined with respect to the requirements of the WHOIS record’s applicable version of the Registrar Accreditation Agreement. ICANN will pull a sample of approximately 200,000 WHOIS records across the entire gTLD name space, and will then perform accuracy testing on a subsample of those records. We published a report (https://whois.icann.org/en/file/whois-ars-phase-2-cycle-1-report-syntax-and…) for Phase 2 Cycle 1 on 23 December 2015 and plan to publish a report of the findings of Phase 2 Cycle 2 in June 2016. More information about the project can be found on whois.icann.org: https://whois.icann.org/en/whoisars. Thank you for your cooperation, ICANN’s GDD Operations Team

5 8

Re: [gtld-tech] FW: Registrar Expiration Date I-D
by Michele Neylon - Blacknight Jan. 21, 2016

Jan. 21, 2016

Francisco Sorry, but why is this needed? What purpose does it serve? Regards Michele -- 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 21/01/2016, 21:55, "gtld-tech-bounces(a)icann.org on behalf of Francisco Arias" <gtld-tech-bounces(a)icann.org on behalf of francisco.arias(a)icann.org> wrote: > >On 1/21/16, 11:59 AM, "Gustavo Lozano" <gustavo.lozano(a)icann.org> wrote: > >>Hello colleagues, >> >>I uploaded an I-D >>(http://www.ietf.org/id/draft-lozano-ietf-eppext-registrar-expiration-date- >>00.txt) in order to define an EPP extension to support the transmission of >>the registrar registration expiration date from the registrar to the >>registry. >> >>This extension is defined in order to support the ICANN Thick Whois Policy >>Recommendation >>(http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf) that >>requires gTLD domain name registries to display the registrar registration >>expiration date in the Registration Data Directory Service (e.g. Whois, >>RDAP). >> >>Your feedback is appreciated. >> >>Regards, >>Gustavo

1 0

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

Jan. 15, 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

WHOIS Data Collection Phase 2 Cycle 2 of WHOIS Accuracy Reporting System (ARS)
by Russ Weinstein Jan. 15, 2016

Jan. 15, 2016

Dear Colleagues, Between 20 January and 17 February 2016, ICANN will be initiating a large volume of WHOIS queries of gTLD registrations as part of its WHOIS Accuracy Reporting System (ARS) project utilizing the following IP addresses to perform the WHOIS queries: IP Addresses: 192.0.32.230/31 and 192.0.47.230/31 A gTLD can expect to receive query rates of 10 queries per minute; we have accounted for RSP’s with multiple gTLD’s and will attempt to limit the queries to 10 per minute across a RSP. We kindly request and appreciate your cooperation in allowing these queries to be processed and ask that you please whitelist the IP addresses provided above. As a reminder, the WHOIS ARS project was established to perform periodic studies to assess the accuracy of the contact information in the WHOIS data, with a goal of identifying opportunities to improve the accuracy of this data over time. The project was established to implement a series of improvements recommended by the WHOIS Review Team and approved by the Board (8 November 2012) on the manner in which ICANN carries out its responsibilities regarding WHOIS. This collection of data will support the next cycle in the WHOIS ARS, Phase 2 Cycle 2, which aims to assess syntax and operability accuracy of the contact information in a gTLD WHOIS record. Accuracy will be determined with respect to the requirements of the WHOIS record’s applicable version of the Registrar Accreditation Agreement. ICANN will pull a sample of approximately 200,000 WHOIS records across the entire gTLD name space, and will then perform accuracy testing on a subsample of those records. We published a report (https://whois.icann.org/en/file/whois-ars-phase-2-cycle-1-report-syntax-and…) for Phase 2 Cycle 1 on 23 December 2015 and plan to publish a report of the findings of Phase 2 Cycle 2 in June 2016. More information about the project can be found on whois.icann.org: https://whois.icann.org/en/whoisars. Thank you for your cooperation, ICANN’s GDD Operations Team

2 2