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

Gustavo Lozano <gustavo.lozano@icann.org> Wed, 07 October 2015 14:00 UTC

Return-Path: <gustavo.lozano@icann.org>
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 BA0E81A90A9 for <eppext@ietfa.amsl.com>; Wed, 7 Oct 2015 07:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level:
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 5yI_6459r2rP for <eppext@ietfa.amsl.com>; Wed, 7 Oct 2015 07:00:30 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D301A9094 for <eppext@ietf.org>; Wed, 7 Oct 2015 07:00:30 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 7 Oct 2015 07:00:27 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Wed, 7 Oct 2015 07:00:27 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: =?Windows-1252?Q?Patrik_Wallstr=F6m?= <pawal@blipp.com>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
Thread-Topic: [eppext] [gtld-tech] RDAP server of the registry
Thread-Index: AQHRAQiF8QwlLt7wHEa5Mfuyers7Pw==
Date: Wed, 7 Oct 2015 14:00:27 +0000
Message-ID: <D23A9BCF.C1455%gustavo.lozano@icann.org>
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> <831693C2CDA2E849A7D7A712B24E257F4A0ABD5A@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <DE7011CD-9673-4A41-8F15-B37B51BE9879@blipp.com>
In-Reply-To: <DE7011CD-9673-4A41-8F15-B37B51BE9879@blipp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3527056817_482256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/KN3Z_K2cOFMy4-O5BiXNW0TmLkw>
Cc: Kaveh Ranjbar <kranjbar@ripe.net>, "gtld-tech@icann.org" <gtld-tech@icann.org>, "eppext@ietf.org" <eppext@ietf.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 14:00:31 -0000

IMHO, this group (EPPEXT) could define a BCP for RDAP implementers (e.g.
clients, DNRs, RIRs) of RDAP. This document could contain text like:

* if you have information about an object, but you know about of another
entity that may have extra information of the same object, you can use a
links members with a rel:related to link to the RDAP server of the other
entity Š (thin DNRs->Registrars, RIRs->NIRs->ISPs, etc)

* HTTPS SHOULD be used, and the RDAP service MUST use the best practices
for secure use of TLS as described in RFC7525 or its successors.

This group (EPPEXT) could define a BCP for DNRs (e.g. ccTLDs, gTLDs, etc).
This document could contain text like:

* if you support IDN registrations, you MUST ....

Maybe the RIRs are interested in defining a BCP for RIRs?

The gTLD profile is a document related to ICANN policies, and like the
gTLD Whois advisory and the technical provisions of the registry agreement
or RAA, should follow the ICANN process (e.g getting feedback from the
ICANN constituencies, public comments, etc).

At this moment, the gTLD profile contains technical implementation
provisions, because there are no documents that define those technical
provisions, but a future version of the gTLD profile could remove the
implementation provisions by referencing to the appropiate RFC(s).

The open issues of appendix A of the gTLD profile should be addressed by
one or several I-Ds, but I don¹t think they are only related to gTLDs. For
example, I know of at least a ccTLD that implements 5.

gTLD Registries want to have full requirements and an implementation plan
for all RDSS (i.e. whois, rdap) related activities, therefore the schedule
to have the gTLD profile ready looks tight.


Regards,
Gustavo

On 10/7/15, 08:33, "EppExt on behalf of Patrik Wallström"
<eppext-bounces@ietf.org on behalf of pawal@blipp.com> wrote:

>
>> On 07 Oct 2015, at 13:22, Hollenbeck, Scott <shollenbeck@verisign.com>
>>wrote:
>> 
>> 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.
>
>I think two documents might be good, one BCP for implementors (however,
>remembering RFC 4641 for DNSSEC, it is way to early in the deployment
>process to create a BCP) and an informational document for ICANNs
>requirements for gTLDs. I don¹t think that the IETF ever distinguishes
>between gTLDs and other TLDs, since this is purely an ICANN distinction..
>
>> 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.
>
>I would prefer if draft-gould-epp-rdap-status-mapping can go to standards
>track as a separate document, as it is beneficial for all TLD registries
>using EPP.
>
>> So I¹m suggesting a new for two or three documents: one or two that
>>describe additional needed functionality and one that describes the op
>
>Yes, agree.
>