[regext] Roman Danyliw's Discuss on draft-ietf-regext-rdap-sorting-and-paging-17: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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.

** 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”.


----------------------------------------------------------------------
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.

** Section 2.4.  Please replace thelastdomainofthepage.com with example.*

** 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.

** 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)

** Section 7.   Per the third paragraph, what is the security issue?  What’s
the threat?

** 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.