Hi Rob,
No problem, don't mention it :-)
Best,
Mario
Il 08/09/2023 15:35, Rob Wilton (rwilton) ha scritto:
Hi Mario,
Sorry to be slow to get back you. I’ve checked the changes in -25
against my comments and it all looks good to me.
I’ve cleared my discuss.
Regards,
Rob
*From:*iesg <iesg-boun...@ietf.org> *On Behalf Of *Mario Loffredo
*Sent:* 28 August 2023 08:57
*To:* Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>
*Cc:* draft-ietf-regext-rdap-reverse-sea...@ietf.org;
regext-cha...@ietf.org; regext@ietf.org; t...@apnic.net
*Subject:* Re: [regext] Robert Wilton's Discuss on
draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Robert,
need to partially correct my comment about the content of table in
Section 12.2.4.2.
The "Reference" field is already defined for the "Reverse Search
Mapping" registry and for all the entries of that registry the value
is the same as that for the entries of the "Reverse Search" registry
as it is explained in the second paragraph of Section 12.2.4.2.
The "Reference" field in the "Reverse Search Mapping" registry is
required to store the link to the documentation supporting the given
mapping.
The "PropetyPath" field allows the requestor to describe the mapping
formally and unambiguously.
Therefore, thinking back, there's no need to introduce a "Description"
property for that registry.
Anyway, if you think the "Description" field should also be included
to provide a brief description of the mapping, I'll add it to both
12.2.4.1 and 12.2.4.2 Sections.
Looking forward to you reply about this and other points.
Best,
Mario
Il 24/08/2023 15:48, Mario Loffredo ha scritto:
Hi Robert,
thanks a lot for your review.
Please find my comments inline.
Il 23/08/2023 15:06, Robert Wilton via Datatracker ha scritto:
Robert Wilton has entered the following ballot position for
draft-ietf-regext-rdap-reverse-search-24: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
Flagging part of the IANA considerations as a DISCUSS, but I think that
this
should be easy to resolve:
(1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries
These registries follow the Specification Required process as
defined
in Section 4.5 of [RFC8126].
The designated expert should prevent collisions and confirm that
suitable documentation, as described in Section 4.6 of [RFC8126], is
available to ensure interoperability. References are not limited
only to RFCs and simple definitions could be described in the
registries themselves.
I'm not sure that "simple definitions could be described in the
registries
themselves" is consistent with the "Specification Required" policy
chosen above.
[ML] You are right. I'll change that sentence as in the following:
References are not limited
only to RFCs but can also locate document published outside of the RFC
path, including informal
documentation.
Does it work for you ?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
[I support John's discuss on normative references.]
I also have some other comments that you may wish to consider:
(2) p 14, sec 12.2.4.2. Initial Content
+==========+==================================================+
| Property | Property Path |
+==========+==================================================+
| fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3] |
+----------+--------------------------------------------------+
| handle | $.entities[*].handle |
+----------+--------------------------------------------------+
| email | $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
+----------+--------------------------------------------------+
| role | $.entities[*].roles |
+----------+--------------------------------------------------+
Would it be helpful for this table to include the "Description" and
"Reference"
properties?
[ML] Do you mean the "Description" and "Reference" related to the
specific mapping for the reverse search property or those related
to the reverse search property ?
In the latter case they are already included in Table 2 and Table
1 respectively.
In the first case, they are missing and must be first added to the
"RDAP Reverse Search Mapping Registry".
Since there might be specifications proposing a diffierent maping
for an existing reverse search property it sounds reasonable to me
to add both of them.
Minor level comments:
(3) p 3, sec 1. Introduction
The protocol described in this specification aims to extend the RDAP
query capabilities and response to enable reverse search based on
the
relationships defined in RDAP between an object class for search and
a related object class. The reverse search based on the domain-
entity relationship is treated as a particular case of such a
generic
model.
This introduction text seems to immediately jump into a defense as to
why it is
okay to standardize this functionality in an RDAP extension. This is
okay, but
I wonder whether it wouldn't be better if the introduction only
included the
last paragraph (i.e., that is stating what extension is defined in this
document), and the rest of the text was moved into a "Background"
subsection of
the introduction.
[ML] Sounds reasonable to me. Then, the new Introduction section
should be arranged as into the following:
1. Introduction
The protocol described in this specification aims to extend the RDAP
query capabilities and response to enable reverse search based on the
relationships defined in RDAP between an object class for search and
a related object class. The reverse search based on the domain-
entity relationship is treated as a particular case of such a generic
model.
1.1 Background
Reverse Whois is a service provided by many web applications that
allows users to find domain names owned by an individual or a company
starting from the owner's details, such as name and email. Even if
it has been considered useful for some legal purposes (e.g.
uncovering trademark infringements, detecting cybercrimes), its
availability as a standardized Whois capability has been objected to
for two main reasons, which now don't seem to conflict with an RDAP
implementation.
.....
.....
.....
Currently, RDAP does not provide any means for a client to search for
the collection of domains associated with an entity [RFC9082]. A
query (lookup or search) on domains can return the array of entities
related to a domain with different roles (registrant, registrar,
administrative, technical, reseller, etc.), but the reverse operation
is not allowed. Only reverse searches to find the collection of
domains related to a nameserver (ldhName or ip) can be requested.
Since an entity can be in relationship with any RDAP object
[RFC9083], the availability of a reverse search as largely intended
can be common to all the object classes allowed for search. Through
a further step of generalization, the meaning of reverse search in
the RDAP context can be extended to include any query for retrieving
all the objects in relationship with another matching a given search
pattern.
Can you please confirm that it would work for you ?
(4) p 7, sec 8. Reverse Searches Based on Entity Details
Reverse search property: fn
RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
Reference: Section 6.2.1 of [RFC6350]
A minor issue, but it wasn't immediately obvious to me what 'fn' is - I
initially presumed that it meant function, so I was wondering if some
more text
would be helpful here, and/or perhaps in the IANA registry that you are
creating.
[ML] FN is a property of the vCard format [RFC6350] representing
the contact name. The JSON format for the vCard data, namely jCard
[RFC7095], is used in RDAP responses [RFC9083] to represent
contact information (see the member "vcardArray" in the JSONPath
expression)
jCard specification states that the property names should be in
lowercase.
The name 'fn' is also used in RDAP as query parameter for
seacrhing contacts by name [RFC9082].
Besides being well-known to RDAP operators, think that the value
of the "Description" field in the "RDAP Reverse Search" registry
makes it clear enough the meaning of the "fn" reverse search property.
Best,
Mario
Regards,
Rob
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Senior Technologist
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
--
Dott. Mario Loffredo
Senior Technologist
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
--
Dott. Mario Loffredo
Senior Technologist
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
