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

[Gustavo Lozano]

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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5045 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20151007/f565ca98/smime.p7s>