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

["Marc Blanchet" <[e-mail]>]

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"
> <[e-mail] on behalf of [e-mail]> wrote:
>
>>
>>> On 07 Oct 2015, at 13:22, Hollenbeck, Scott 
>>> <[e-mail]>
>>> 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.
>>