RDAP server of the registry
Hello, The first version of the ICANN gTLD profile was published days ago, (see: http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html), this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN
Gustavo, I'd very much prefer to see the profile described in an I-D and developed using the IETF's consensus process. I'm also willing to back up that preference with writing help as needed. I'll have specific comments on the profile itself "soon". Scott From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Monday, October 05, 2015 10:34 AM To: gtld-tech@icann.org Cc: eppext@ietf.org Subject: [eppext] RDAP server of the registry Hello, The first version of the ICANN gTLD profile was published days ago, (see: http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html), this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN
Hi Scott, With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D. On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs. All the best, Kaveh.
On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”.
Scott
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Monday, October 05, 2015 10:34 AM To: gtld-tech@icann.org Cc: eppext@ietf.org Subject: [eppext] RDAP server of the registry
Hello,
The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html <http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html>), this document describes basic parameters and objects to be implemented by ICANN-contracted parties.
The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date).
The gTLD profile support the same functionality with the following mechanism:
The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object.
Questions for this group:
* What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D?
Regards, Gustavo Lozano ICANN
It’s more than just policy, Kaveh – it’s implementation requirements that I’m suggesting should be developed with community consensus. Internet-Drafts can be (and have been) written to document implementations of IETF standards. Here’s one example that became an Informational RFC: https://datatracker.ietf.org/doc/rfc3054/ An Informational-intended document that describes protocol option settings could be developed for RDAP in a very similar way. What’s in the document now is incomplete, but it would be a very good start, and as I said – I’m willing to help write. Scott From: Kaveh Ranjbar [mailto:kranjbar@ripe.net] Sent: Tuesday, October 06, 2015 10:05 AM To: Hollenbeck, Scott Cc: Gustavo Lozano; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [gtld-tech] RDAP server of the registry Hi Scott, With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D. On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs. All the best, Kaveh. On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”. Scott From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Monday, October 05, 2015 10:34 AM To: gtld-tech@icann.org<mailto:gtld-tech@icann.org> Cc: eppext@ietf.org<mailto:eppext@ietf.org> Subject: [eppext] RDAP server of the registry Hello, The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html), this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN
Thank you Scott, I am sold, so +1 on Scott’s suggestion. All the best, Kaveh.
On 06 Oct 2015, at 14:53, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
It’s more than just policy, Kaveh – it’s implementation requirements that I’m suggesting should be developed with community consensus. Internet-Drafts can be (and have been) written to document implementations of IETF standards. Here’s one example that became an Informational RFC:
https://datatracker.ietf.org/doc/rfc3054/ <https://datatracker.ietf.org/doc/rfc3054/>
An Informational-intended document that describes protocol option settings could be developed for RDAP in a very similar way. What’s in the document now is incomplete, but it would be a very good start, and as I said – I’m willing to help write.
Scott
From: Kaveh Ranjbar [mailto:kranjbar@ripe.net] Sent: Tuesday, October 06, 2015 10:05 AM To: Hollenbeck, Scott Cc: Gustavo Lozano; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [gtld-tech] RDAP server of the registry
Hi Scott,
With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D.
On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs.
All the best, Kaveh.
On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com <mailto:shollenbeck@verisign.com>> wrote:
Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”.
Scott
From: EppExt [mailto:eppext-bounces@ietf.org <mailto:eppext-bounces@ietf.org>] On Behalf Of Gustavo Lozano Sent: Monday, October 05, 2015 10:34 AM To: gtld-tech@icann.org <mailto:gtld-tech@icann.org> Cc: eppext@ietf.org <mailto:eppext@ietf.org> Subject: [eppext] RDAP server of the registry
Hello,
The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html <http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html>), this document describes basic parameters and objects to be implemented by ICANN-contracted parties.
The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date).
The gTLD profile support the same functionality with the following mechanism:
The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object.
Questions for this group:
* What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D?
Regards, Gustavo Lozano ICANN
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. 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. So I’m suggesting a new for two or three documents: one or two that describe additional needed functionality and one that describes the operational profile. Completion of the operational profile will likely have a dependency on policy development work in ICANN circles. Scott From: Kaveh Ranjbar [mailto:kranjbar@ripe.net] Sent: Tuesday, October 06, 2015 5:57 PM To: Hollenbeck, Scott Cc: Gustavo Lozano; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [gtld-tech] RDAP server of the registry Thank you Scott, I am sold, so +1 on Scott’s suggestion. All the best, Kaveh. On 06 Oct 2015, at 14:53, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: It’s more than just policy, Kaveh – it’s implementation requirements that I’m suggesting should be developed with community consensus. Internet-Drafts can be (and have been) written to document implementations of IETF standards. Here’s one example that became an Informational RFC: https://datatracker.ietf.org/doc/rfc3054/ An Informational-intended document that describes protocol option settings could be developed for RDAP in a very similar way. What’s in the document now is incomplete, but it would be a very good start, and as I said – I’m willing to help write. Scott From: Kaveh Ranjbar [mailto:kranjbar@ripe.net] Sent: Tuesday, October 06, 2015 10:05 AM To: Hollenbeck, Scott Cc: Gustavo Lozano; gtld-tech@icann.org<mailto:gtld-tech@icann.org>; eppext@ietf.org<mailto:eppext@ietf.org> Subject: Re: [gtld-tech] RDAP server of the registry Hi Scott, With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D. On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs. All the best, Kaveh. On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”. Scott From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Monday, October 05, 2015 10:34 AM To: gtld-tech@icann.org<mailto:gtld-tech@icann.org> Cc: eppext@ietf.org<mailto:eppext@ietf.org> Subject: [eppext] RDAP server of the registry Hello, The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html), this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN
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.
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.
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.
-----Original Message----- From: Gustavo Lozano [mailto:gustavo.lozano@icann.org] Sent: Wednesday, October 07, 2015 10:00 AM To: Patrik Wallström; Hollenbeck, Scott Cc: Kaveh Ranjbar; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
[snip]
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.
Gustavo, what's driving that schedule? How does it fit with the RDDS policy development processes that are either under way or being considered? The EWG I was part of made a number of recommendations that depend on RDAP. Where do those recommendations come into play? This gTLD registry operator wants to be sure that we do this once, we do it so that we don't have to undo things in the future, and we make implementation decisions based on consensus policies. If that takes time, so be it. Scott
On 10/7/15, 10:41, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
-----Original Message----- From: Gustavo Lozano [mailto:gustavo.lozano@icann.org] Sent: Wednesday, October 07, 2015 10:00 AM To: Patrik Wallström; Hollenbeck, Scott Cc: Kaveh Ranjbar; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
[snip]
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.
Gustavo, what's driving that schedule? How does it fit with the RDDS policy development processes that are either under way or being considered? The EWG I was part of made a number of recommendations that depend on RDAP. Where do those recommendations come into play?
The schedule for implementing the thick Whois policy that is under way.
This gTLD registry operator wants to be sure that we do this once, we do it so that we don't have to undo things in the future, and we make implementation decisions based on consensus policies. If that takes time, so be it.
I think that we share the same objective. The gTLD profile was sent to the RySG, RrSG, ICANN gtld-tech mailing list, and this group in order to obtain feedback. The RDAP profile will be published once that the ICANN-contracted parties agree that it¹s ready. This is the same the process that we used with the Whois clarification advisory. The schedule that Francisco described in his email (i.e. http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html) appears to work from our perspective, but based on the feedback, it may not work. A great percentage of the provisions in the gTLD profile are related to ICANN policy, and some are just a translation of the requirements in the Registry Agreement and the Whois advisory (I.e. https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-2 7-en) to RDAP. There are provisions that could be part of a BCP, but I don't think that there is an issue. We can work in the gTLD profile and BCP(s) in parallel. Once the BCP(s) are ready, the gTLD profile is modified or a new version is released. I think that is really important to consider all users of RDAP (I.e. ccTLDs, gTLDs, RIRs) if the WG decides to work on BCP(s). Regards, Gustavo
Scott
Scott, the term "consensus policies" has a specific and formal meaning at ICANN. Were you using that meaning in your post? All best, --Greg -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Hollenbeck, Scott Sent: Wednesday, October 07, 2015 10:41 AM To: Gustavo Lozano; Patrik Wallström Cc: gtld-tech@icann.org; eppext@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:41:25 AM
-----Original Message----- From: Gustavo Lozano [mailto:gustavo.lozano@icann.org] Sent: Wednesday, October 07, 2015 10:00 AM To: Patrik Wallström; Hollenbeck, Scott Cc: Kaveh Ranjbar; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
[snip]
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.
Gustavo, what's driving that schedule? How does it fit with the RDDS policy development processes that are either under way or being considered? The EWG I was part of made a number of recommendations that depend on RDAP. Where do those recommendations come into play? This gTLD registry operator wants to be sure that we do this once, we do it so that we don't have to undo things in the future, and we make implementation decisions based on consensus policies. If that takes time, so be it. Scott * Hollenbeck, Scott <shollenbeck@verisign.com> * Issuer: Symantec Corporation - Unverified
-----Original Message----- From: Greg Aaron [mailto:greg@illumintel.com] Sent: Wednesday, October 07, 2015 1:00 PM To: Hollenbeck, Scott; 'Gustavo Lozano'; 'Patrik Wallström' Cc: gtld-tech@icann.org; eppext@ietf.org Subject: RE: [gtld-tech] [eppext] RDAP server of the registry
Scott, the term "consensus policies" has a specific and formal meaning at ICANN. Were you using that meaning in your post?
Yes, in both the ICANN and IETF contexts. There's work to be done in both places. Scott
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@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gustavo Lozano Sent: Wednesday, October 07, 2015 10:00 AM To: Patrik Wallström; Hollenbeck, Scott Cc: gtld-tech@icann.org; eppext@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@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.
* Gustavo Lozano <gustavo.lozano@icann.org> * Issuer: DigiCert Inc - Unverified
Hi Scott, I agree with your suggestions on writing IETF documents of RDAP additional functionality. And a BCP document seems also necessary for registries to implement RDAP servers. 1. one or two RDAP extension documents Besides the issues you mentioned, I'd like to propose to add the reseller information as an optional extension in the RDAP response. Having discussed in WG and last IETF meeting, I think most of WG agree that it would be good to have the reseller included in RDAP/WHOIS. 2. BCP document As for the BCP document, we are interested in contributing text and some implementation experience. Since we have already implemented almost all of the necessary and additional RDAP functionality and existing technical documents could be provided. Regards, Linlin Zhou From: Hollenbeck, Scott Date: 2015-10-07 19:22 To: Kaveh Ranjbar CC: gtld-tech@icann.org; eppext@ietf.org; Gustavo Lozano Subject: Re: [eppext] [gtld-tech] RDAP server of the registry 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. 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. So I’m suggesting a new for two or three documents: one or two that describe additional needed functionality and one that describes the operational profile. Completion of the operational profile will likely have a dependency on policy development work in ICANN circles. Scott From: Kaveh Ranjbar [mailto:kranjbar@ripe.net] Sent: Tuesday, October 06, 2015 5:57 PM To: Hollenbeck, Scott Cc: Gustavo Lozano; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [gtld-tech] RDAP server of the registry Thank you Scott, I am sold, so +1 on Scott’s suggestion. All the best, Kaveh. On 06 Oct 2015, at 14:53, Hollenbeck, Scott <shollenbeck@verisign.com> wrote: It’s more than just policy, Kaveh – it’s implementation requirements that I’m suggesting should be developed with community consensus. Internet-Drafts can be (and have been) written to document implementations of IETF standards. Here’s one example that became an Informational RFC: https://datatracker.ietf.org/doc/rfc3054/ An Informational-intended document that describes protocol option settings could be developed for RDAP in a very similar way. What’s in the document now is incomplete, but it would be a very good start, and as I said – I’m willing to help write. Scott From: Kaveh Ranjbar [mailto:kranjbar@ripe.net] Sent: Tuesday, October 06, 2015 10:05 AM To: Hollenbeck, Scott Cc: Gustavo Lozano; gtld-tech@icann.org; eppext@ietf.org Subject: Re: [gtld-tech] RDAP server of the registry Hi Scott, With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D. On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs. All the best, Kaveh. On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com> wrote: Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”. Scott From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano Sent: Monday, October 05, 2015 10:34 AM To: gtld-tech@icann.org Cc: eppext@ietf.org Subject: [eppext] RDAP server of the registry Hello, The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html), this document describes basic parameters and objects to be implemented by ICANN-contracted parties. The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date). The gTLD profile support the same functionality with the following mechanism: The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object. Questions for this group: * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group. * What is your opinion about documenting this mechanism in an I-D? Regards, Gustavo Lozano ICANN
participants (7)
-
Greg Aaron -
Gustavo Lozano -
Hollenbeck, Scott -
Kaveh Ranjbar -
Linlin Zhou -
Marc Blanchet -
Patrik Wallström