Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

[Mario Loffredo <[e-mail]>]

Hi James,

again my comments below.

Il 26/04/2022 19:07, Gould, James ha scritto:
>
> Mario,
>
> My feedback is embedded below.
>
> -- 
>
> JG
>
>
>
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *Mario Loffredo <[e-mail]>
> *Date: *Tuesday, April 26, 2022 at 11:12 AM
> *To: *James Gould <[e-mail]>, 
> "ietf=[e-mail]" <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] WG LAST CALL: 
> draft-ietf-regext-rdap-reverse-search
>
> Hi James,
>
> thanks a lot for your feeedback.
>
> Please find my responses inline.
>
> Il 26/04/2022 14:17, Gould, James ha scritto:
>
>     I did a review of the latest version of the draft
>     (draft-ietf-regext-rdap-reverse-search-10), and below is my feedback:
>
>     1.Abstract
>
>     a.It states, “This document describes RDAP query extensions”.  
>     Shouldn’t it be “this document describes an RDAP query extension”
>     in the singular form?
>
> [ML] Since the new version introduces a new path to obtain information 
> about the supported reverse searches and new response providing that 
> information, I'll change the sentence as in the following:
>
> ".... this document describes RDAP query and response extensions ... "
>
> JG – I still view the functionality defined with the specification as 
> defining a single extension.  This is reflected in the registration of 
> a single RDAP Conformance value in section 3.
>
>     1.Introduction
>
>      .It is not clear what adopted ad hoc strategies effectively
>     mitigate the impact of reverse searches.  Additionally, a standard
>     search is much less powerful than implementing a reverse search,
>     so I don’t view them as equivalent from a server processing
>     perspective.  Some clarity of how a standard search is equivalent
>     to a reverse search would be helpful or I would remove the statement.
>
> [ML] I changed that paragraph in the new version as in the following:
>
> The other objection to the implementation of a reverse search 
> capability has been connected with its impact on server processing.
> However, the core RDAP specifications already define search queries, 
> with similar processing requirements, so the distinction on
> which this object is based is not clear.
>
> Does it look fine to you? Should I explicitly refer to searching 
> domains for nsLdhName or nsIp when talikng about "search queries, with 
> similar processing requirements" ?
>
> JG – A nit on your proposed language is to change “which this object” 
> to “which this objection”.
>
[ML] Good catch. Corrected.
>
> If you really feel that the reverse search doesn’t have a material 
> difference in server processing from the search defined in section 3.2 
> of [RFC9082], then you can provide clarity in the draft.  The language 
> in draft-ietf-regext-rdap-reverse-search-10 states that there are ad 
> hoc strategies to mitigate the impact of reverse search and that 
> standard search is equivalent to reverse search.  If this is true, 
> then I would clarity the ad hoc strategies used and explain how the 
> standard search can be considered equivalent to reverse search.  Since 
> you’re defining a new form of search, I don’t believe you can use the 
> revised language that states that the distinction on which the 
> objection is based is not clear.  I believe the reverse search is much 
> different and will require an elastic search capability that is not 
> the case for the standard search, which is a material difference.
>
[ML] I wouldn't go into detail with the strategy each registry adopts to 
implement the reverse search. It generally depends on the way 
information is represented and stored, and the policy to restrict the 
access to the reverse search (and standard search) features. Each 
registry could decide each own strategy to implement both the standard 
search and reverse search. The meaning of that text is that RFC9082 
already includes two reverse searches based on the domain-nameserver 
relationship. So, in theory,  the objection about the additional 
processing effort needed to implement a reverse search compared to the 
standard search should fall away because, if a reverse search needed an 
ad-hoc search engine, this would also occur for some standard searches.

Obviously, in practice, if you want to implement a reverse search based 
on an entity detail involving regularly billion of contacts, it might be 
advisable to follow an elastic search based approach but this is not the 
rule of thumb and, anyway, the same implementation considerations can be 
made with regard to the standard searches.

>     1.
>
>     .How is the domain-entity relationship treated with a special
>     focus on its privacy implications? Clarification would be helpful.
>
> [ML] Would it sound better the following sentence ?
>
> The reverse search based on the domain-entity relationship is treated 
> as a particular case, with a special focus on privacy implications of 
> querying for sensitive information.
>
> JG – Where is the special focus on privacy implications for sensitive 
> information defined within the draft?  If it exists, I would reference 
> it, and if it doesn’t exist, I would add the definition.
>
[ML] The special focus is represented by the presence of the "Privacy 
Considerations" section whose purpose is to focus on the implications of 
performing reverse searches based on a contact PII.

Then, the measures to mitigate the privacy risks listed in that section 
are presented in Appendix A.

>     1.RDAP Path Segment Specification
>
>     a.Is it defining OPTIONAL extensions or an OPTIONAL extension?  I
>     believe the specification is defining a single RDAP extension, so
>     the singular form would be better.
>
> [ML] Removed that sentence from the new version.
>
>     1.
>
>     a.The searchable-resource-type is limited to only resource types
>     defined in RFC 9082.  Shouldn’t it also support new resource types
>     defined by future RDAP extensions?  My recommendation is to have
>     it read “it MUST be one of the resource types for searched defined
>     in Section 3.2 of [RFC9082] or a resource type extension, …”.
>
> [ML] Agreed.
>
>     1.
>
>     a.The related-resource-type is limited to only resource types
>     defined in RFC 9082.  Shouldn’t it also support new resource types
>     defined by future RDAP extensions?  My recommendation is to have
>     it read “it MUST be one of the resource types for lookup defined
>     in Section 3.1 of [RFC9082] or a resource type extension…”.
>
> [ML] Agreed.
>
>     1.RDAP Conformance
>
>     a.Based on the definition of a single value, the specification is
>     defining a single RDAP extension and not multiple RDAP extensions
>     as indicated in the Abstract and Introduction.
>
> [ML] Complying to rdapConformance tag “reverse_search_0” means 
> implementing, at a least, one reverse search  by setting a pair 
> <searchable-resource-type, related-resource-type> in the generic query 
> model and, optionally, support the reverse search metadata request and 
> response.
>
> JG - If they are two separate extensions defined within the 
> specification, then you should consider creating an RDAP conformance 
> value for each.  I consider the reverse search as a single extension 
> with multiple features.
>
[ML] Me too. I'll change the document accordingly.
>
> Best,
>
> Mario
>
>     -- 
>
>     JG
>
>
>
>
>     *James Gould
>     *Fellow Engineer
>     [e-mail]
>     <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     Verisign.com
>     <http://secure-web.cisco.com/1r7sTFyYTLDPFqqhtUXzJ2vWry8SgnLjU6qqgAcIGpfvXR73o4RG2lVwCFJ4MyUuqU829jWxNGNDh3iobZMWiMqPPUn-8BG5BpdavX9_myk4LW2nBlVfuRjnYMzV1MMrCoJ2ysU3-shJCU8FlrwfPPEdmJsvQ6FWTcNtxnWYdun4qN5M-DcgjI1ChW92UhEVcEFSc6Sld5knsz0-3zT1aMtogToJ8A0eY72mW-SWyA8GLhy3zxRgmKyCucP7uiBrH/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *regext <[e-mail]>
>     <mailto:[e-mail]> on behalf of Antoin Verschuren
>     <ietf=[e-mail]>
>     <mailto:ietf=[e-mail]>
>     *Date: *Monday, April 25, 2022 at 9:44 AM
>     *To: *regext <[e-mail]> <mailto:[e-mail]>
>     *Subject: *[EXTERNAL] Re: [regext] WG LAST CALL:
>     draft-ietf-regext-rdap-reverse-search
>
>     WGLC for this document should have ended last week.
>
>     But since there is still a good discussion going on between the
>     Document Shepherd and the authors, the chairs have decided to
>     extend this WGLC for another week till Monday May 2nd.
>
>     Since we only had 2 valid support messages (not being the authors
>     or shepherd) we would like to ask for more support from the WG as
>     well. 2 is very little to declare consensus. Could others please
>     review as soon as Mario has published a new version with the
>     comments from Scott and Tom included?
>
>         Op 11 apr. 2022, om 15:50 heeft Antoin Verschuren
>         <ietf=[e-mail]> het volgende geschreven:
>
>         Reminder,
>
>         1 more week remaining for this WGLC.
>
>         In addition to the authors, we received 3 responses so far.
>
>         Regards,
>
>         Jim and Antoin
>
>             Op 4 apr. 2022, om 15:18 heeft Antoin Verschuren
>             <ietf=[e-mail]> het volgende geschreven:
>
>             Dear Working Group,
>
>             The authors of the following working group document have
>             indicated that it is believed to be ready for submission
>             to the IESG for publication as a standards track document:
>
>             https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
>             <https://secure-web.cisco.com/1ua3m1ygiPX3451lX_xaT9Z-dfjlDPcKJyp8avIFHXnHWndX3bvBPwhtbQU3yIZXz19hRC-18gI3rg7jzG1i7rI75UL5jo68iKqKYLCg2_-lG3zN36bOo2h-UDJuSccsr1TqPJzr-sh4pSgnm5JHfFINaH9HK5TbDl00Ye37nMZ6ecLZQrfipasSmiQTDKvrTDbd1MMXTyIRk2Q3nbS8JPcsGYYX3xs62rg93ONBCUdy48YH1INSVQUwIV2i3d8PO/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-reverse-search%2F>
>
>             This WG last call will end at close of business, Monday,
>             18 April 2022.
>
>             Please review this document and indicate your support (a
>             simple “+1” is sufficient) or concerns with the
>             publication of this document by replying to this message
>             on the list.
>
>             The document shepherd for this document is Tom Harrison.
>
>             Regards,
>
>             Jim and Antoin
>
>
>
>
>
>             _______________________________________________
>             regext mailing list
>             [e-mail]
>             https://www.ietf.org/mailman/listinfo/regext
>             <https://secure-web.cisco.com/1kfNcYaJoIUSsbsZHzMzOCxV8KU5KRl032G2m7kStPPtWAkvupFlGTrF3mdNDoZB6aAEeWScZp-2YGXtZQkOXJQDLhqeYZRuoKLibQgPh5MYxXmSWTrUoGvueW7-MqrqXR7JRrBvzV83DIWiFXWNY3jnCaTHnULxNr9jzF85I3rWCR1rt7FtxGzqnhZ1cfbzUC5sBuPwm25K0gTpvMQJq_ted3_YFBLjbvvJyVUmeMz11Cr2Z1SGQf1d_HFXivX_liAe3lX8EL6_yYJiopgkjqA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
>         _______________________________________________
>         regext mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/regext
>         <https://secure-web.cisco.com/1kfNcYaJoIUSsbsZHzMzOCxV8KU5KRl032G2m7kStPPtWAkvupFlGTrF3mdNDoZB6aAEeWScZp-2YGXtZQkOXJQDLhqeYZRuoKLibQgPh5MYxXmSWTrUoGvueW7-MqrqXR7JRrBvzV83DIWiFXWNY3jnCaTHnULxNr9jzF85I3rWCR1rt7FtxGzqnhZ1cfbzUC5sBuPwm25K0gTpvMQJq_ted3_YFBLjbvvJyVUmeMz11Cr2Z1SGQf1d_HFXivX_liAe3lX8EL6_yYJiopgkjqA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
>
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/regext  <https://secure-web.cisco.com/1kfNcYaJoIUSsbsZHzMzOCxV8KU5KRl032G2m7kStPPtWAkvupFlGTrF3mdNDoZB6aAEeWScZp-2YGXtZQkOXJQDLhqeYZRuoKLibQgPh5MYxXmSWTrUoGvueW7-MqrqXR7JRrBvzV83DIWiFXWNY3jnCaTHnULxNr9jzF85I3rWCR1rt7FtxGzqnhZ1cfbzUC5sBuPwm25K0gTpvMQJq_ted3_YFBLjbvvJyVUmeMz11Cr2Z1SGQf1d_HFXivX_liAe3lX8EL6_yYJiopgkjqA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
> -- 
> Dr. 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: [phone]
> Web:http://www.iit.cnr.it/mario.loffredo  <http://secure-web.cisco.com/1vzZgmPpVcV7JP1dRsSzP9WfolrlcJ7_lI4LE-MSvxAa7PeHUq9JUUPDvJ6a65l4TB95-Vxtbvh-Wch0P74hG65C5--GbqiZFFu0Eqml7GpuqSt7LKJxKPX7ctgH6Nj8eGVp5v0282VrA1GAEsp1VTc0l3gFp9y4FEULK8gempF3sk5pjJVazn062tTur23eg3ezQHMGJDel9NtAcNySzVeByAgwgDDmQ_xl5Y9Mwe7imaTWuZXM5pRQOH9kS2Rye7TGJLjphZllnP-GT7Ouj7w/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. 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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo