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
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *Mario Loffredo <[email protected]>
*Date: *Tuesday, April 26, 2022 at 11:12 AM
*To: *James Gould <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
*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
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
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 <[email protected]>
<mailto:[email protected]> on behalf of Antoin Verschuren
<[email protected]>
<mailto:[email protected]>
*Date: *Monday, April 25, 2022 at 9:44 AM
*To: *regext <[email protected]> <mailto:[email protected]>
*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
<[email protected]> 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
<[email protected]> 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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
