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-paging/
----------------------------------------------------------------------
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
