Mario, My feedback is embedded below.
-- JG [cid:image001.png@01D8596E.8CEEBB40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Tuesday, April 26, 2022 at 11:12 AM To: James Gould <jgo...@verisign.com>, "ietf=40antoin...@dmarc.ietf.org" <i...@antoin.nl>, "regext@ietf.org" <regext@ietf.org> 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”. 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. 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. 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. Best, Mario -- JG [cid:image002.png@01D8596E.8CEEBB40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 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 <regext-boun...@ietf.org><mailto:regext-boun...@ietf.org> on behalf of Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org><mailto:ietf=40antoin...@dmarc.ietf.org> Date: Monday, April 25, 2022 at 9:44 AM To: regext <regext@ietf.org><mailto:regext@ietf.org> 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=40antoin...@dmarc.ietf.org<mailto:ietf=40antoin...@dmarc.ietf.org>> 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=40antoin...@dmarc.ietf.org<mailto:ietf=40antoin...@dmarc.ietf.org>> 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 regext@ietf.org<mailto:regext@ietf.org> 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 regext@ietf.org<mailto:regext@ietf.org> 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 regext@ietf.org<mailto:regext@ietf.org> 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: +39.0503153497 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
