Re: [regext] RDAP reverse search draft feedback

Mario Loffredo <> Mon, 03 August 2020 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A0C83A0D3D for <>; Mon, 3 Aug 2020 02:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.947
X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dYuHrjkkfIcA for <>; Mon, 3 Aug 2020 02:51:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 770983A0D41 for <>; Mon, 3 Aug 2020 02:51:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C8A8B802A0; Mon, 3 Aug 2020 11:51:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KYxaxmEdaCTU; Mon, 3 Aug 2020 11:51:40 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9D6F5B801CF; Mon, 3 Aug 2020 11:51:40 +0200 (CEST)
To: Jasdip Singh <>, "" <>
References: <>
From: Mario Loffredo <>
Message-ID: <>
Date: Mon, 3 Aug 2020 11:48:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C690D346CF0D26429D600563"
Content-Language: it
Archived-At: <>
Subject: Re: [regext] RDAP reverse search draft feedback
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2020 09:51:49 -0000

Hi Jansdip,

thansk so much for your feedback. I'm finally happy to focus on 
technical aspects.

I provide my comments to your feedback below.

Il 31/07/2020 21:01, Jasdip Singh ha scritto:
> Hello Mario, Scott,
> Please find my feedback on 
>  below:
>  1. Agree with the overall usefulness of this draft to cover the
>     missing/needed search scenarios.
[ML] Happy to hear that.
>  2. Not sure if we need to specifically mention in the draft but just
>     noting that Regional Internet Registries (RIRs) also implement the
>     domains search for their reverse DNS zones. :) Something to
>     consider for the Introduction section?
[ML] Hopefully. As I replied to George, I confess that I'm not 
experienced in the numbers space. Any contribution to make the draft 
more comprehensive is very welcome. I think that especially the concepts 
in section "Privacy Considerations" work also in the context of the 
numbers space but the examples I have reported there are tailored only 
for the namespace.
>  3. Why introduce the keyword “reverse” in the search path? Is it to
>     distinguish from the related reverse search scenarios (e.g.
>     domains by nsIp) defined in 7843bis? In light of introducing a new
>     extension for this draft, the “reverse” keyword may be redundant.
[ML] The main reason is to clearly identify the paths dedicated to 
reverse search so RDAP providers can more easily control the access to 
reverse search services on a per-path basis. Moreover, maybe in the next 
future, RDAP servers might implement additional services and having 
different paths make the mapping between the services and the users more 
manageable at the implementation level. In the REST context, resources 
can be easily protected according to their path.
>  4. Instead of defining the generic reverse search path
>     {resource-type}/reverse/{role}?{property}=<search pattern>, would
>     it be better to take a specific search path, say domains versus
>     nameservers versus entities, and define the new query parameters
>     (that fill the current search gaps) for each of them
>     section-by-section? Please ignore this comment if the intent here
>     is to pivot around the roles defined in the IANA RDAP JSON Values
>     registry.
[ML] I'm deeply convinced that specifying the entity role is fundamental 
for an effective implementation of a reverse search feature. For two 

1. to furtherly map the reverse search services against the user 
profiles: searching domains for a technical contact might be allowed to 
more users than searching domains for a registrant

2. to restrict the scope of a reverse search query: a reverse search 
without specifying a role usually takes longer and involves much more 
objects than doing the same for a specific role and I think that rarely 
a reverse search would be requested without considering a role.

Anyway, the draft takes all the scenarios.

I report as a response to the following comment the reasons why I have 
opted for defining the role in the path rather than as a query parameter.

>  5. Knowing that it gets more complex but is it possible that folks
>     may need to pass multiple query parameters for conjunctive
>     criteria? If so, {resource-type}/reverse/{role}?{property}=<search
>     pattern> may need to evolve to account for multiple query parameters.
[ML] Provided that we agree that specifying the role in a reverse search 
query would be useful, I reported here in the following some possible 
solutions with the related pros and cons:

1. replicating the properties used for reverse searching for the 
possible roles in the query parameters (e.g. registrantFn, technicalHandle)

   Pros: very compact in itself and in a conjunctive criteria (e.g. 

   Cons: not very effective because there would be a proliferation of 
query parameters, and, as I wrote above,  the role specification in the 
path might help the implementers' burden in controlling the access to 
the reverse search services. In my opinion, not very neat from the 
conceptual point of view as well.

2. letting role be a query parameter (e.g. fn=XXXXX&role=registrant).

   Pros: simple solution (it was the first solution I proposed)

   Cons: unusable in building conjuntive criteria and, like the soluion 
aforementioned, unpractical for controlling the accesses.

3. specifying the role in the query path:

  Pros: the most effective solution for controlling the accesses and 
very flexible and conceptually neat.

  Cons: unusable in conjunctive criteria, at least in those mentioning 
two reverse search properties.

   Anyway, this is true if we think that GET must be the only HTTP 
method available in RDAP. It is well known that GET allows to specify a 
query where parameters are joined solely in AND. It would be desireable 
that all boolean operators should be allowed and, in my opinion, this 
could be done only if the query is submitted via POST . I have already 
implemented a draft version of this feature. I don't wanna go into much 
detail on this service here but the key aspects are:

   a. a POST can be submitted on the specific path "/query" (e.g. 

  b. the request body is a JSON map including the parameters normally 
used in a GET query like count, sort, fieldSet plus a parameter named 
"query"  to deliver a complex search predicate as a JSON object. All the 
boolean operators are allowed, likewise predicates at different nesting 
level. Search properties related to RDAP contents are reported as 
strings: "nsLdhName", "reverse/registrant/fn"

  4. any other solution not listed before.

>  6. Though not directly related with this draft, just an observation
>     from 7483bis that there the IP Network and Autonomous System
>     Number objects can be listed in an entity (an org) lookup response
>     but not the Domain objects. Not sure if this was by design?
[ML] I imagine that the reverse relationship between entities and 
domains has not been addressed in RFC7483bis to leave it for the future.
>  7. May be just me but found the abstract a bit verbose. Move some of
>     it to the Introduction section?
[ML] Basically, I haven't changed the abstract since the first 
submission. At that time, I wasn't very experienced in writing an IETF 
I-D. After many more submissions and comments, I am more knowlegeable so 
I definitively agree with you that the abstract must be reorganized.



> Thanks,
> Jasdip
> _______________________________________________
> regext mailing list

Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240