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

[Greg Aaron]

Gustavo correctly notes some important things --ICANN has contractual
requirements that tell registries and registrars what data they MUST deliver
(currently via the WHOIS protocol), and ICANN is now working on how that
data should be delivered via RDAP.   Whatever document is created is going
to be binding on registries and registrars.  As per the 2013 RAA, once RDAP
spec is mature “ICANN reserves the right to specify alternative formats and
protocols, and upon such specification, the Registrar will implement such
alternative specification as soon as reasonably practicable.”  The new gTLD
registry agreements contain similar.

RDAP’s supposedly been designed to deliver what ICANN might require of its
registrars and registries.  If so, we are embarking on an exercise in
implementation in the gTLD world, with ICANN as the policy authority.  BCPs
for ccTLDs etc. might be nice, but seem like a distraction from the
immediate task at hand.

The implementation requirements should certainly be well-thought-out, should
receive input (and hopefully collegial buy-in) from the parties who will
have to make it work, and should be clearly documented.  As Gustavo says,
ICANN has process to deliver that.  Requiring “community consensus” about
the contents, as Scott suggested, is a different and higher standard from
what has been agreed to in the ICANN contracts.

All best,
--Greg



-----Original Message-----
From: gtld-tech-bounces at icann.org [mailto:gtld-tech-bounces at icann.org] On
Behalf Of Gustavo Lozano
Sent: Wednesday, October 07, 2015 10:00 AM
To: Patrik Wallström; Hollenbeck, Scott
Cc: gtld-tech at icann.org; eppext at ietf.org
Subject: Re: [gtld-tech] [eppext] RDAP server of the registry

* PGP - S/MIME Signed by an unverified key: 10/7/2015 at 10:00:17 AM

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 at ietf.org on behalf of pawal at blipp.com> wrote:

>
>> On 07 Oct 2015, at 13:22, Hollenbeck, Scott 
>><shollenbeck at 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.
>

* Gustavo Lozano <gustavo.lozano at icann.org>
* Issuer: DigiCert Inc - Unverified