Subject: [eppext] RDAP server of the registry

From: Gustavo Lozano <[email-masked]>
Date: Mon, 5 Oct 2015 14:34:13 +0000

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Oct 2015 17:11:22 +0000

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:[email-masked]] On Behalf Of Gustavo Lozano
Sent: Monday, October 05, 2015 10:34 AM
To: [email-masked]
Cc: [email-masked]
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.

* 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Oct 2015 18:53:52 +0000

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:[email-masked]]
Sent: Tuesday, October 06, 2015 10:05 AM
To: Hollenbeck, Scott
Cc: Gustavo Lozano; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]] On Behalf Of Gustavo Lozano
Sent: Monday, October 05, 2015 10:34 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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.

Regards,
Gustavo Lozano
ICANN

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Oct 2015 11:22:53 +0000

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:[email-masked]]
Sent: Tuesday, October 06, 2015 5:57 PM
To: Hollenbeck, Scott
Cc: Gustavo Lozano; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Scott

From: Kaveh Ranjbar [mailto:[email-masked]]
Sent: Tuesday, October 06, 2015 10:05 AM
To: Hollenbeck, Scott
Cc: Gustavo Lozano; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [gtld-tech] RDAP server of the registry

Hi Scott,

All the best,
Kaveh.

Scott

Hello,

Regards,
Gustavo Lozano
ICANN

---

From: Patrik Wallström <[email-masked]>
Date: Wed, 7 Oct 2015 14:33:08 +0200

> On 07 Oct 2015, at 13:22, Hollenbeck, Scott <[email-masked]> wrote:
> 

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..

> 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 eith…

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.

---

From: Gustavo Lozano <[email-masked]>
Date: Wed, 7 Oct 2015 14:00:27 +0000

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"
<[email-masked] on behalf of [email-masked]> 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:
>> 
>> 3. The ³the last update date and time of the database used to generate
>>the RDAP responses² event.
>> 
>> 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.
>

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 07 Oct 2015 10:08:21 -0400

On 7 Oct 2015, at 10:00, Gustavo Lozano wrote:

> 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.

> entity  (thin DNRs->Registrars, RIRs->NIRs->ISPs, etc)
>
>>> On 07 Oct 2015, at 13:22, Hollenbeck, Scott 
>>> <[email-masked]>
>>> wrote:
>>>
>>> would be time well spent. Back to Gustavo¹s original question
>>>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Oct 2015 14:41:26 +0000

> -----Original Message-----
> From: Gustavo Lozano [mailto:[email-masked]]
> Sent: Wednesday, October 07, 2015 10:00 AM
> To: Patrik Wallström; Hollenbeck, Scott
> Cc: Kaveh Ranjbar; [email-masked]; [email-masked]
> Subject: Re: [eppext] [gtld-tech] RDAP server of the registry

[snip]

> 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

---

From: Gustavo Lozano <[email-masked]>
Date: Wed, 7 Oct 2015 16:38:05 +0000

>those recommendations come into play?

The schedule for implementing the thick Whois policy that is
under way.

>implementation decisions based on consensus policies. If that takes time,

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 8 Oct 2015 13:33:10 +0000

> From: Greg Aaron [mailto:[email-masked]]
> Sent: Wednesday, October 07, 2015 1:00 PM
> To: Hollenbeck, Scott; 'Gustavo Lozano'; 'Patrik Wallström'
> Cc: [email-masked]; [email-masked]
> 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

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 9 Oct 2015 10:59:25 +0800

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: [email-masked]; [email-masked]; 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…

 

 

 
 
Scott

Thank you Scott,

All the best,
Kaveh.
 
On 06 Oct 2015, at 14:53, Hollenbeck, Scott <[email-masked]> wrote:

 
 
Scott

Hi Scott,

 
All the best,
Kaveh.
 
On 05 Oct 2015, at 13:11, Hollenbeck, Scott <[email-masked]> wrote:

Scott

Hello,

 

 

Regards,
Gustavo Lozano
ICANN

---

From: Kaveh Ranjbar <[email-masked]>
Date: Tue, 6 Oct 2015 10:04:55 -0400

Hi Scott,

All the best,
Kaveh.

> 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.
>

---

From: Kaveh Ranjbar <[email-masked]>
Date: Tue, 6 Oct 2015 17:56:32 -0400

Thank you Scott,

All the best,
Kaveh.

> https://datatracker.ietf.org/doc/rfc3054/ <https://datatracker.ietf.org/doc/rfc3054/>
> 
> On 05 Oct 2015, at 13:11, Hollenbeck, Scott <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: EppExt [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gustavo Lozano
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: "Greg Aaron" <[email-masked]>
Date: Wed, 7 Oct 2015 11:27:05 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Gustavo Lozano
Sent: Wednesday, October 07, 2015 10:00 AM
To: Patrik Wallström; Hollenbeck, Scott
Cc: [email-masked]; [email-masked]
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

* 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.

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).

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.

Regards,
Gustavo

On 10/7/15, 08:33, "EppExt on behalf of Patrik Wallström"
<[email-masked] on behalf of [email-masked]> 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.
>
>> 3. The ³the last update date and time of the database used to 
>>generate the RDAP responses² event.
>> 
>> 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 
>>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.
>

* Gustavo Lozano <[email-masked]>
* Issuer: DigiCert Inc - Unverified

---

From: "Greg Aaron" <[email-masked]>
Date: Wed, 7 Oct 2015 13:00:04 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Hollenbeck, Scott
Sent: Wednesday, October 07, 2015 10:41 AM
To: Gustavo Lozano; Patrik Wallström
Cc: [email-masked]; [email-masked]
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

[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.

Scott

* Hollenbeck, Scott <[email-masked]>
* Issuer: Symantec Corporation - Unverified