-----Original Message-----
From: Mario Loffredo <mario.loffr...@iit.cnr.it>
Sent: Thursday, September 24, 2020 10:56 AM
To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org>
Cc: draft-ietf-regext-rdap-sorting-and-pag...@ietf.org; regext-cha...@ietf.org;
regext@ietf.org; Tom Harrison <t...@apnic.net>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-regext-rdap-sorting-and-
paging-17: (with DISCUSS and COMMENT)
Hi Roman,
thanks a lot for your review. Please find my comments inline.
Il 23/09/2020 15:33, Roman Danyliw via Datatracker ha scritto:
Roman Danyliw has entered the following ballot position for
draft-ietf-regext-rdap-sorting-and-paging-17: 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 to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-pa
ging/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
** Canonical Reference for JSONPath. Section 2.1/2.3.1 describes
field(s) whose syntax is in JSONPath. The shepherd’s note
acknowledges that there is no good reference for JSONPath.
Nevertheless, the text needs to be clearer on where to turn to for guidance.
(1) Section 2.3.1 says: “Such a reference could be
expressed by using a JSONPath. The JSONPath in a JSON document
[RFC8259] is equivalent to the XPath [W3C.CR-xpath-31-20161213] in a
XML document.
(2) The JSONPaths are provided according to the Goessner v.0.8.0
specification [GOESSNER-JSON-PATH].
(3) Further documentation about
JSONPath operators used in this specification is included in
Appendix A.
Taking the perspective of the implementer, which of these three
resources is canonical for understanding JSONPath:
(a) [W3C.CR-xpath-31-20161213] = a reference marked normative that has
nothing to do with JSON but suggests equivalence through a few examples.
(b) [GOESSNER-JSON-PATH] = a reference marked as informative which is
being used to describe the normative mapping between JSONPaths of the
RDAP fields in the text, and is the actual description of the JSONPath
syntax. The shepherd’s note points out the difficulty of using this
as a normative reference
(c) Appendix A = self-contained text which describes JSONPath
independent of
(a) and (c). As an aside, I’m not sure of the completeness of this write-up.
Additionally, the IETF is currently considering it’s own version of
JSONPath -- https://datatracker.ietf.org/doc/charter-ietf-jsonpath/
IMO, the fig leaf of citing [W3C.CR-xpath-31-20161213] is
inappropriate (as in, it isn’t the actual reference) and unnecessary
(as in, it’s just there to meet the letter of having a normative
reference). I recommend being practical about the need:
-- Use language to the effect of saying the “JSONPath used here is a
flavor defined in XXX”
-- Make “XXX” be Appendix A.
-- Bolster Appendix A to say something to the effect of “this version
of JSONPath is inspired by [W3C.CR-xpath-31-20161213] (informative
reference) and an articulation of what is used in production
[GOESSNER-JSON-PATH] (informative reference)”; and where necessary, add
more language around the syntax.
This approach will also allow for new JSONPath WG to define a variant
which is not strictly compatible (if that’s where the work goes).
I’m open to an alternative approach. I just want to end up with a
single clear reference of where to read about this documents particular
JSONPath syntax.
[ML] I agree it is less misleading. I'll rearrange Section 2.3.1. and,
consequently,
Appendix A as you suggest. However, I would like to outline that JSONPath
operators used in this document are commonly supported. No script expression
has been used. The current draft of JSONPath WG Charter mentions Goessner'
specification as the original and reference proposal and states that:
The WG will develop a standards-track JSONPath specification, with the
primary goal of capturing the common semantics of existing implementations
and, where there are differences, choosing semantics with the goal of causing
the least disruption amongJSONPath users.
Therefore, I'm extremely confident that this document will be perfectly
compliant with the outcomes of JSONPath WG.
** Section 2.4. Does this specification provide any normative
guidance of “cursor” beyond an opaque value constrained by ABNF? The
text notes the notion of “offsets”, “limits”, and “keys”, Base64, CSV
but these appear to be referenced as examples. However, Appendix B
contains normative language around “limit” and “offset”.
[ML] No, it doesn't. Cursor implementation strategies is out of the scope of
this
document. The purpose of Appendix B is to show how the two most popular
strategies to implement pagination can be considered two ways of supporting
the cursor operator.
I agree with you that "MUST" keywords in Appendix B are inappropriate so I'll
remove them (e.g. "MUST return" is changed into "returns")
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you for the SECDIR review, Rifaat (Shekh-Yusef)!
** Section 2.3.1. The text notes that JSON Pointer is “hard to use”.
It wasn’t clear where the mandate to use JSON Pointer came.
[ML] JSONPath and JSONPointer are the most popuar notations used for
selecting a value in a JSON content but, unfortunately, neither of them is
suitable for representing a sorting property in an RDAP query because they
aren't coincise and URL-safe. This specification adopts a simple string as a
shortcut to identify a sorting property and provides metadata to unambiguosly
bind such string to an RDAP response field. For this purpose, JSONPath is
preferred to JSONPointer because some RDAP response values, which are
suitable for sorting, can't be identified through JSONPointer.
Is it clear enough in your opinion? If yes, should I rearrange Section
2.3.1 to consider such clarification?
** Section 2.4. Please replace thelastdomainofthepage.com with
example.*
[ML] OK. I'll harmonize this example with the examples of RDAP queries.
I have already used "/domains?name=example*.com" in all the RDAP queries.
Additionally, I'll replace "key=thelastdomainofthepage.com"
with "key=example-N.com".
** Section 2.4 Is there any semantics to read into “&cursor=wJ…” in
Figure 5 beyond it being blob conforming to the cursor ABNF?
Editorially, the text doesn’t reference it to explain what’s there.
[ML] It's only an example of a cursor parameter in an RDAP query. I could use
the value deriving from a simple Base64 conversion of either
"offset=100,limit=50" or "key=example-N.com" but I'm afraid it would be
misunderstood with a recommendation to use an underlying pagination
strategy and a specific encoding for cursor values. As I wrote above, cursor
implementation by servers is not a matter of this document and, obviously, a
simple Base64 conversion is not recommended to encode the cursor values.
** Section 7. The issue of paging is being framed as primarily a
security issue is puzzling. It seems to me that this is about
providing a more usable API for the client which has a net benefit of
reducing the resources required to serve the comparable information.
If DoS is really the concern, the queries can be rate or resource
limited by the application or the underlying RDMS (whose underlying
capabilities are explained in earlier text as making this process
efficient)
[ML] The concern is about resource exhaustion in general and resource
exhaustion at server side can be caused by a targeted DOS attack but also by a
number of search requests producing huge result sets. Through the current
RDAP capabilities, a server can implement some measures:
mitigating the excessive number of queries by a single consumer (i.e.
query rate limits), restricting the potential size of the result sets (e.g.
refusing
wildcard prefixed search patterns). Other measures can be addressed through
the features defined in this document: discouraging huge result set scrolling by
providing the users with the count information, splitting a huge result set in a
sequence of sustainable result sets through pagination, sorting the results so
that relevant information can be found without traversing all the result set.
** Section 7. Per the third paragraph, what is the security issue? What’s
the threat?
[ML] The threat is resource exhaustion and consequent denial of service.
If implemented, the capabilities described in this document would contribute to
decrease the number of unnecessary search requests and limit the result set
size so that servers can mitigate the risk of resource exhaustion.
** Section 7. Concur with Eric, there appears to be an implicit
assumption that returning subsets of a record set is “fast” and so is
counting the number of records. IMO, this isn’t a problem if this is a stated
assumption.
[ML] Well. I think that it's a well known assumption. Counting, especially when
supported by indexes, is much faster than selection.
Hope I caught the meaning of your comments. Please don't hesitate to request
further clarifications.
Looking forward for your reply.
Best,
Mario
--
Dr. Mario Loffredo
Systems and Technological Development Unit Institute of Informatics and
Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA,
Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
