Hi Jansdip,
thanks for you review.
Please find my comments inline.
Il 08/03/2023 23:41, Jasdip Singh ha scritto:
Hello Mario,
Please find below my comments on this draft:
- Title: Would it be better to re-title the doc as simply "Registration Data Access Protocol (RDAP)
Reverse Search" since we tend to mention it in discussions as "reverse search" and not
"reverse search capabilities"?
[ML] Res, "RDAP Reverse Search" sounds better.
- Section 3: Typo "resorce" in "triple <searchable resorce type, related resource type,
property>".
[ML] Good catch.
- Section 3: "Servers MUST NOT provide or implement unregistered reverse searches or
unregistered reverse search mappings." ... Does "unregistering" entries from these
IANA registries mean removing them, or simply marking them as deprecated? If the latter, do we need
a status field in these registries to differentiate the active entries from the deprecated ones?
Not clear about it.
[ML] Unregistered means merely not included in the registries and the
sentence looks clear to me. Don't think the registries' entries should
be removed or deprecated as well.
Registries can decide on their own to deprecate either properties or
mappings and how long should be the deprecation period. Obviously,
deprecations can be finally achieved de facto but we cannot be
completely sure that some entries are no more active.
- Section 8: "The presence of a predicate on the reverse search property "role" means that the RDAP response
property "roles" must contain at least the specified role." ... Should "must" be changed to
"MUST"?
[ML] Yes.
- Section 12.1: "Intended usage: This extension identifier is used for reverse search URI path
segments." ... Should we elaborate here that this extension identifier is also used as a prefix in the
"reverse_search_properties" and "reverse_search_properties_mapping" data members' names?
[ML] Are you OK with the following?
Intended usage: This extension identifier is used for both URI path segments
and response extensions related to the reverse search in RDAP.
- Section 13: "Since reverse search requests and responses could contain Personally Identifiable
Information (PII), reverse search functionality SHOULD be available over HTTPS only." ... Should
"SHOULD" be changed to "MUST"? IIRC, we strongly discourage using HTTP (versus HTTPS) in
RDAP.
[ML] Put SHOULD instead of MUST initially because registries can
implement other or further measures to enforce both privacy and
security. Anyway, I admit that the usage of HTTPS is particularly
recommended in this context so MUST is preferred.
- Appendix A: Just curious if the reason why the "Federated Authentication for the
Registration Data Access Protocol (RDAP) using OpenID Connect" draft is not
mentioned in this draft is because we think that the latter would be on the standards
track before the former?
[ML] Not just because of it.
As said in the previous point, RDAP providers are free to implement
their security measures as they see fit. Using OpenID is an option.
Registries could implement additional OpenID measures that are not
described in rdap-openid such as those presented in Appendix A,
specifically time-based and attribute-based access control features.
That being said, I can't find a valid reason to keep a dependency on an
ongoing document included in the informative references.
Looking forward to your reply or any comment from others.
Best,
Mario
Overall, this work has evolved pretty well. :)
Thanks,
Jasdip
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
