Subject: [regext] draft-blanchet-regext-entityid2rdapserver-00.txt

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 11 Mar 2019 16:49:19 -0400

Hello,
  this draft just posted is the result of discussions that happened in 
ICANN RDAP profile discussions, where a missing piece was found in the 
use case of thin domain registries. However, the proposal in the draft 
is generic and may apply to other use cases in the future if necessary. 
The draft is not fully baked but more than enough to have a discussion 
on the issue and the proposed solution.

Looking for comments and reviews,

Marc.

Subject: New Version Notification for draft-blanchet-regext-entityid2rdapserver-00.txt
From: [email-masked]
To: "Marc Blanchet" <[email-masked]>
Date: Mon, 11 Mar 2019 13:45:21 -0700

A new version of I-D, draft-blanchet-regext-entityid2rdapserver-00.txt
has been successfully submitted by Marc Blanchet and posted to the
IETF repository.

Name:		draft-blanchet-regext-entityid2rdapserver
Revision:	00
Title:		Finding Additional Registration Data (RDAP) Service
Document date:	2019-03-11
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-blanchet-regext-entityid2rdapserver-00.txt
Status:         https://datatracker.ietf.org/doc/draft-blanchet-regext-entityid2rdapserver/
Htmlized:       https://tools.ietf.org/html/draft-blanchet-regext-entityid2rdapserver-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-blanchet-regext-entityid2rdapserver

Abstract:
   This document specifies a method to find which Registration Data
   Access Protocol (RDAP) server is authoritative to answer additional
   information for a query already answered by another server.  It is
   based on an entity id to RDAP server location mapping registry
   managed by IANA.  One use case of this specification is the domain
   registry RDAP server providing a referral URL to the registrar RDAP
   server, based on the registrar entity id, for information that the
   registrar is authoritative for such as the contact or reseller
   information.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Andy Newton <[email-masked]>
Date: Wed, 20 Mar 2019 10:18:00 -0400

On Mon, Mar 11, 2019 at 04:49:19PM -0400, Marc Blanchet wrote:
> Hello,
>  this draft just posted is the result of discussions that happened in ICANN
> RDAP profile discussions, where a missing piece was found in the use case of
> thin domain registries. However, the proposal in the draft is generic and
> may apply to other use cases in the future if necessary. The draft is not
> fully baked but more than enough to have a discussion on the issue and the
> proposed solution.
> 

A couple of comments:

1. Why is a new bootstrap registry being created? This seems to be doing the
same thing as the object tag registry, except this only applies to RDAP
entities.

2. The do-this-or-that of step 4 in section 3 is far from ideal. There should
only be one step, and that should be to use the referral URL in 4A. The servers
that, for reasons that escape me, do not know the URLs for the registrars can
use the bootstrap to formulate the referral URL on behalf of the client thus
keeping client complexity to a minimum.

-andy