Re: [regext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)

[Mario Loffredo <[e-mail]>]

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 <[e-mail]> *On Behalf Of *Mario Loffredo
> *Sent:* 28 August 2023 08:57
> *To:* Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> *Cc:* [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> *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
>
>         [e-mail]
>
>         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: [phone]
>
>     Web:http://www.iit.cnr.it/mario.loffredo
>
>
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>     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: [phone]
> 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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo