Subject: [regext] Fwd: I-D Action: draft-blanchet-regext-rdap-deployfindings-00.txt

From: "Marc Blanchet" <[email-masked]>
Date: Sun, 02 Jun 2019 11:39:39 -0400

Hello,
  please find this draft which describes findings in current deployment 
of RDAP. Various levels of severity.

Regards, Marc.

Subject: I-D Action: draft-blanchet-regext-rdap-deployfindings-00.txt
From: [email-masked]
To: <[email-masked]>
Date: Sun, 02 Jun 2019 08:37:56 -0700
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : RDAP Deployment Findings and Update
        Author          : Marc Blanchet
	Filename        : draft-blanchet-regext-rdap-deployfindings-00.txt
	Pages           : 10
	Date            : 2019-06-02

Abstract:
   Registration Access Data Protocol(RDAP) is being deployed in domain
   and IP address registries.  This document describes issues and
   findings while interfacing with the known server implementations and
   deployments.  It also provides recommendations for the
   specifications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-blanchet-regext-rdap-deployfindings/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-blanchet-regext-rdap-deployfindings-00
https://datatracker.ietf.org/doc/html/draft-blanchet-regext-rdap-deployfindings-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 3 Jun 2019 14:33:54 +0200

Hi Marc,

thank you for this document. I consider it very helpful.

I agree with you that some information included in the RFCs about RDAP 
need to be clarified to facilitate the implementers' work  and the 
overall client-server interoperability.

For example, which is the relationship between the rdapConformance 
values and the registered extenions? I mean, if I registered the 
extension "itNic",  should I simply insert "itNic" into the 
rdapConformance array or should I insert "itNic_..." ? In the second 
case, should the inserted value be compliant with a default format 
(i.e.  "itNic_level_0" or "itNic_version_0" or "itNic_0") ?

With regard to section 3.3, in my opinion, the context URI should always 
be set to the current query. In this way, it could be much easier to 
define the meaning of  each "rel" value. In order to avoid such problems 
and make the links about sorting, paging and subsetting clearly 
identifiable by the client, I have wrapped them in reserved elements 
instead of providing them as notices.

I don't completely agree with you about the content of section 6.1. If 
we read the definition of  search patterns based on a name in RFC7482, 
it seems that, even in these cases,  partial matching would not be 
allowed since the pattern should represent a name in LDH or U-label 
format. For sure we need to clarify the search patterns definition but I 
would opt to allow partial matching also when the pattern represents an 
IP address.

In addition, I think that also the string "IANA Registrar ID" should be 
considered among the currently used but unregistered values.

Best,

mario

Il 02/06/2019 17:39, Marc Blanchet ha scritto:

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail:[email-masked]
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 03 Jun 2019 10:29:19 -0400

On 3 Jun 2019, at 8:33, Mario Loffredo wrote:

> we read the definition of  search patterns based on a name in 
> RFC7482, it seems that, even in these cases,  partial matching would 
> not be allowed since the pattern should represent a name in LDH or 
> U-label format. For sure we need to clarify the search patterns 
> definition but I would opt to allow partial matching also when the 
> pattern represents an IP address.

well, partial matching of IP address was not the intent of the search. 
So your suggestion is much larger than mine. I was just trying to fix 
the wording to be crystal clear of the intent.

Marc.