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.