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

"Marc Blanchet" <marc.blanchet@viagenie.ca> Wed, 07 October 2015 14:08 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 A13FA1A90F4 for <eppext@ietfa.amsl.com>; Wed, 7 Oct 2015 07:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level:
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 u_0AI9DF4JhV for <eppext@ietfa.amsl.com>; Wed, 7 Oct 2015 07:08:22 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93B611A90F1 for <eppext@ietf.org>; Wed, 7 Oct 2015 07:08:22 -0700 (PDT)
Received: from [192.168.1.109] (modemcable093.65-160-184.mc.videotron.ca [184.160.65.93]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E0ED7403E5; Wed, 7 Oct 2015 10:08:21 -0400 (EDT)
From: "Marc Blanchet" <marc.blanchet@viagenie.ca>
To: "Gustavo Lozano" <gustavo.lozano@icann.org>
Date: Wed, 07 Oct 2015 10:08:21 -0400
Message-ID: <2FB29E84-2C2D-4A7E-A4F4-8298A1908EEC@viagenie.ca>
In-Reply-To: <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> <D23A9BCF.C1455%gustavo.lozano@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/Y3QfbeFzuY8BjtD3zO8lCyQcIdQ>
Cc: Patrik =?utf-8?q?Wallstr=C3=B6m?= <pawal@blipp.com>, "gtld-tech@icann.org" <gtld-tech@icann.org>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, "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:08:24 -0000


On 7 Oct 2015, at 10:00, Gustavo Lozano wrote:

> IMHO, this group (EPPEXT) could define a BCP for RDAP implementers 
> (e.g.
> clients, DNRs, RIRs) of RDAP.

if that happens, then we should definitively recharter/rename the 
working group along the lines discussed before: i.e. aka registration 
protocols working group.

Marc.

> 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.
>>