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
regext@ietf.org
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
