Hi Pawel,
thanks a lot for your review.
Please find my comments inline.
Il 15/11/2022 17:28, Pawel Kowalik ha scritto:
Hi Mario,
I reviewed this draft and have 2 questions:
- Reverse search property - the draft defines a fixed list of 4 search
properties. Do I understand it right that adding some other reverse
search properties, which are to be interoperable, would require a new
RFC? Wouldn't it be better to have an IANA registry for the search
properties? Actually JSON Values Registry for "redacted name" proposed
in draft-ietf-regext-rdap-redacted has almost the same semantic
meaning: giving labels to certain JSONPaths.
[ML] The document allows the definition of custom reverse search
properties that are related to response extensions.
A server that includes additional fields in its objects in accordance
with the extensibility provisions of section 6 of [RFC7480] MAY
support the use of those fields in search conditions, in the same way
as for the search conditions defined in this section.
The 4 properties listed in the document match the recommendation
presented in Section 6 and cover the relationships between the three
searchable resource types currently available and the only possible
related resource type (i.e. entity) for which a reverse search property
hasn't already been defined (see. nsLdhName and nsIp for
domain-nameserver relationship).
Hence, the definition of further interoperable reverse search properties
based on other relationships is deferred to other documents introducing
new resource types (either searchable or related).
That said, a specific registry could certainly provide a centralized
list of reverse search properties thus improving interoperability.
Each entry in the registry could contain the following fields:
- Searchable resource type
- Related resource type
- Property name
- RDAP property path
- Reference
Do you agree ?
Is there any other proposal from everyone else?
- Discovery - how should the client learn which reverse search
properties are supported? Even those 4 defined in the draft are a
SHOULD requirement, so do not have to be supported. I see this
particular issue was discussed on the mailing list
https://mailarchive.ietf.org/arch/msg/regext/dgdPRRnQbWNhL0VVa_dq7xM-a5M/
but there was no continuation/conclusion.
Have used "SHOULD" because RDAP operators may support some of them, not all.
WIth regard to the discussion, guess the conclusion was subordinated to
the outcomes of the other discussion about the extension identifiers.
Surely, we could quickly resume the discussion on that point.
I would suggest two possible solution:
1) Simply extend the help response with the array of supported reverse
search properties . Each object of the array should include as many
members as the registry fields. The first free fields should be required
while "RDAP property path" and "reference" could be set only for custom
properties (i.e not included in the registry) .
2) Follow Tom's approach of having different metadata endpoints. In this
case, the first two fields would be omitted and only "property name"
would be required.
What's your (Tom's and others') opinion ?
Best,
Mario
Kind regards,
Pawel
Am 15.11.22 um 08:57 schrieb Mario Loffredo:
Hi all,
as you may note from the change log and diff tool, I have made a
couple of arrangements to the document:
- Have moved RFC6973 from Normative to Informative References because
it is an Informational RFC. I apologize if I missed this mistake
before WGLC.
- Have removed the reference to rdap-openid . The reference was used
in the Appendix as a mere hint to a possible way to specify a purpose
for a reverse search query and, IMO, its removal don't change the
meaning of the sentence where It is cited. After the discussion at
last aside meeting at IETF, it seemed to me appropriate to remove
that reference to avoid a dependency from a document in deep
progress. The only open dependency left is on jsonpath-base which is
expected to end the evaluation process shortly.
Both the changes have been agreed with the shepherd.
Best,
Mario
-------- Messaggio Inoltrato --------
Oggetto: [regext] I-D Action:
draft-ietf-regext-rdap-reverse-search-15.txt
Data: Mon, 14 Nov 2022 06:13:16 -0800
Mittente: internet-dra...@ietf.org
Rispondi-a: regext@ietf.org
A: i-d-annou...@ietf.org
CC: regext@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Registration Protocols Extensions WG
of the IETF.
Title : Registration Data Access Protocol (RDAP) Reverse search
capabilities
Authors : Mario Loffredo
Maurizio Martinelli
Filename : draft-ietf-regext-rdap-reverse-search-15.txt
Pages : 14
Date : 2022-11-14
Abstract:
The Registration Data Access Protocol (RDAP) does not include query
capabilities for finding the list of domains related to a set of
entities matching a given search pattern. In the RDAP context, an
entity can be associated with any defined object class. Moreover,
other relationships between object classes exist and might be used
for providing a reverse search capability. Therefore, a reverse
search can be applied to other use cases besides the classic domain-
entity scenario. This document describes an RDAP extension that
allows servers to provide a reverse search feature based on the
relationship defined in RDAP between an object class for search and
any related object class. The reverse search based on the domain-
entity relationship is treated as a particular case.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-15
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-reverse-search-15
Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Pawel Kowalik
Head of Product Management
--
DENIC eG, Kaiserstraße 75 - 77, 60329 Frankfurt am Main, GERMANY
E-Mail:pawel.kowa...@denic.de, Fon: +49 173 3087096
https://www.denic.de
Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian Röthler
Vorsitzender des Aufsichtsrats: Daniel Rink
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am
Main
Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art. 13,
Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten durch
DENIC finden Sie unterhttps://www.denic.de/datenverarbeitung-allgemein/
_______________________________________________
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
