Re: [eppext] [gtld-tech] RDAP server of the registry

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 07 October 2015 11:23 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530C01B2E26 for <eppext@ietfa.amsl.com>; Wed, 7 Oct 2015 04:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbLo5CS3dnfP for <eppext@ietfa.amsl.com>; Wed, 7 Oct 2015 04:22:59 -0700 (PDT)
Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AFF1B2E28 for <eppext@ietf.org>; Wed, 7 Oct 2015 04:22:57 -0700 (PDT)
Received: by qgev79 with SMTP id v79so677166qge.3 for <eppext@ietf.org>; Wed, 07 Oct 2015 04:22:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=Ob1QIsgIYY27x+L/0sB74QKI4Vxt6lQ4YwR8b4YbSU4=; b=mRlmZtFtwk5d8ehode1gD14q+TZVU6LWcN6Q5a3kHSHx3HavoYw8bIXdYbVmSJesCd KspxXZsgzAaEIwruGAU3ZxwshFokUVCPnVdzaHjmBrRvsZreVo2vudEcZGJtQoh2VgKp 4nJEn0Rz4xGnAhUZ9C6ZXz+2ZABToKMcwG0ANAud2dEND339p/c93RD3frSkLF4m5pfR Xgv72jOU+Bpo3bC7NjCfMU5D1gFk1A7pbJ4RLpmQ7nkTXdM8TLzjLp+uQ6dxQR0NI/gR ZkFmD93pGqxWIc/pKgHQnsjN9mJ3fn+CcXQr+gCyT+jItgKxgOuCOIDRx8zq5q+O1sha UXTQ==
X-Gm-Message-State: ALoCoQlfQsHjSvcrh7xlwfyvB1VDNbwwmpPS5NzbPYRLRptg2SGJs93A4yEErYklUTZau+d2y0Oru7Uv00KwOSwayl2C4QWb1g==
X-Received: by 10.140.202.204 with SMTP id x195mr589402qha.7.1444216976464; Wed, 07 Oct 2015 04:22:56 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id 101sm477364qkr.12.2015.10.07.04.22.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 Oct 2015 04:22:56 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t97BMtSs027466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Oct 2015 07:22:55 -0400
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 7 Oct 2015 07:22:55 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Kaveh Ranjbar <kranjbar@ripe.net>
Thread-Topic: [gtld-tech] RDAP server of the registry
Thread-Index: AQHQ/3rntucFay3MHE6AZbmw28rIeZ5dIheggAGh9YCAAAlGYIAAen8AgACX8ZA=
Date: Wed, 07 Oct 2015 11:22:53 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A0ABD5A@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
References: <D23802A0.C0D5E%gustavo.lozano@icann.org> <831693C2CDA2E849A7D7A712B24E257F4A0A9B8A@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <9FBF2B96-1FF2-4A5F-9697-388AEA71BF67@ripe.net> <831693C2CDA2E849A7D7A712B24E257F4A0AB58B@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <88246F46-92E4-4848-BC5B-2275E942C4AF@ripe.net>
In-Reply-To: <88246F46-92E4-4848-BC5B-2275E942C4AF@ripe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4A0ABD5ABRN1WNEXMBX02vc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/lDmOcg97EK5sLrgxaR2-I51PQD8>
Cc: "gtld-tech@icann.org" <gtld-tech@icann.org>, "eppext@ietf.org" <eppext@ietf.org>, Gustavo Lozano <gustavo.lozano@icann.org>
Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 11:23:02 -0000

Another possibility: a Best Current Practice (BCP) document. We’ll need to think about what we think the “best practices” should be, but that would be time well spent. Back to Gustavo’s original question…

Yes, I’d like to see bits like this documented in an I-D that describes things that need to be added to RDAP for use by gTLD registries and registrars. However, I’m going to suggest that we take an inventory of those omissions and try to organize them in some way so that we don’t end up with multiple small documents that might instead be represented as a smaller number of larger documents. The profile document already has a good list of open issues; here’s a thought on how to organize and address them.

1. Gustavo’s links suggestion below.

2. Jim Gould’s status value mapping:

https://datatracker.ietf.org/doc/draft-gould-epp-rdap-status-mapping/

3. The “the last update date and time of the database used to generate the RDAP responses” event.

4. An event with the expiration date of the Registrar.

5. If a Registry supports multiple host objects with the same name, the Registry MUST support the capability to respond with a set of host objects in response to a name server lookup.

I think these could be combined into one “RDAP extensions for gTLD Registries and Registrars” document. Additional search functionality, including Boolean search support, could be described in either this document or another document. If it’s simple, include it all in one document. If it isn’t, separate the topics so that the simpler ones can move ahead more quickly.

So I’m suggesting a new for two or three documents: one or two that describe additional needed functionality and one that describes the operational profile. Completion of the operational profile will likely have a dependency on policy development work in ICANN circles.

Scott

From: Kaveh Ranjbar [mailto:kranjbar@ripe.net]
Sent: Tuesday, October 06, 2015 5:57 PM
To: Hollenbeck, Scott
Cc: Gustavo Lozano; gtld-tech@icann.org; eppext@ietf.org
Subject: Re: [gtld-tech] RDAP server of the registry

Thank you Scott,

I am sold, so +1 on Scott’s suggestion.

All the best,
Kaveh.

On 06 Oct 2015, at 14:53, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote:

It’s more than just policy, Kaveh – it’s implementation requirements that I’m suggesting should be developed with community consensus. Internet-Drafts can be (and have been) written to document implementations of IETF standards. Here’s one example that became an Informational RFC:

https://datatracker.ietf.org/doc/rfc3054/

An Informational-intended document that describes protocol option settings could be developed for RDAP in a very similar way. What’s in the document now is incomplete, but it would be a very good start, and as I said – I’m willing to help write.

Scott

From: Kaveh Ranjbar [mailto:kranjbar@ripe.net]
Sent: Tuesday, October 06, 2015 10:05 AM
To: Hollenbeck, Scott
Cc: Gustavo Lozano; gtld-tech@icann.org<mailto:gtld-tech@icann.org>; eppext@ietf.org<mailto:eppext@ietf.org>
Subject: Re: [gtld-tech] RDAP server of the registry

Hi Scott,

With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D.

On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs.

All the best,
Kaveh.

On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote:

Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”.

Scott

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano
Sent: Monday, October 05, 2015 10:34 AM
To: gtld-tech@icann.org<mailto:gtld-tech@icann.org>
Cc: eppext@ietf.org<mailto:eppext@ietf.org>
Subject: [eppext] RDAP server of the registry

Hello,

The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html), this document describes basic parameters and objects to be implemented by ICANN-contracted parties.

The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date).

The gTLD profile support the same functionality with the following mechanism:

The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object.

Questions for this group:

* What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group.
* What is your opinion about documenting this mechanism in an I-D?


Regards,
Gustavo Lozano
ICANN