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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 23 Sep 2020 06:33:53 -0700

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.

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 24 Sep 2020 16:56:20 +0200

Hi Roman,

thanks a lot for your review. Please find my comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/

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

> referenced as examples.  However, Appendix B contains normative language around

[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")

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

> 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.
> (whose underlying capabilities are explained in earlier text as making this
[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
[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.
> 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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 24 Sep 2020 15:11:34 +0000

Hi Mario!

> -----Original Message-----
> From: Mario Loffredo <[email-masked]>
> Sent: Thursday, September 24, 2020 10:56 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Tom Harrison <[email-masked]>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-regext-rdap-sorting-and-
> paging-17: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> > 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
> > ** 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.
> >
> > 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
> >
> > 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”
> >
> > -- 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:
> 
> 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.
> 
> > ** 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

> > ** 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.
> 
> 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.
> 
> I have already used "/domains?name=example*.com" in all the RDAP queries.
> Additionally, I'll replace "key=thelastdomainofthepage.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
> 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)
> 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:
> 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.
> >
> 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.
> 
> 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

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 24 Sep 2020 18:14:03 +0200

Hi Roman,

thanks a lot for your quick reply.  I can't report entirely here the 
edits involving Section 2.3.1 and Appendix A. I'll publish a new version 
as soon as possible.

Please let me know if there is something that still doesn't work for you.

Thanks again for your feedback,

Mario