Subject: Re: [regext] RDAP reverse search draft feedback

From: Mario Loffredo <[email-masked]>
Date: Mon, 3 Aug 2020 11:48:41 +0200

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 
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ 
>  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 
reasons:

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. 
registrantFn=XXXXX&technicalHandle=YYYYY)

   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. 
domains/query)

  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.

Best,

Mario

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

-- 
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
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Jasdip Singh <[email-masked]>
Date: Mon, 3 Aug 2020 23:47:30 +0000

Thanks for explaining various options, Mario. That’s a reasonable justification for a role to be in the path segment, especially for access control and search efficiency.

Jasdip

From: Mario Loffredo <[email-masked]>
Date: Monday, August 3, 2020 at 5:51 AM
To: Jasdip Singh <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [regext] RDAP reverse search draft feedback

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

  1.  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 reasons:

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.

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.

  1.  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. registrantFn=XXXXX&technicalHandle=YYYYY)

  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.

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

 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. domains/query)

 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"