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

[Roman Danyliw <[e-mail]>]

Hi Mario!

> -----Original Message-----
> From: Mario Loffredo <[e-mail]>
> Sent: Thursday, September 24, 2020 10:56 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; Tom Harrison <[e-mail]>
> 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")

Both of these proposed edits work for me.  Thanks.

Regards,
Roman

> >
> > ----------------------------------------------------------------------
> > 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: [phone]
> Mobile: [phone]
> Web: http://www.iit.cnr.it/mario.loffredo