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

Mario Loffredo <> Thu, 24 September 2020 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A9603A0E68; Thu, 24 Sep 2020 07:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uYcUmlZGPOth; Thu, 24 Sep 2020 07:59:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8DEFE3A0E95; Thu, 24 Sep 2020 07:59:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E57EB80378; Thu, 24 Sep 2020 16:59:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m35GOx25rFy9; Thu, 24 Sep 2020 16:59:39 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 8C13DB80375; Thu, 24 Sep 2020 16:59:39 +0200 (CEST)
To: Roman Danyliw <>, The IESG <>
Cc:,,, Tom Harrison <>
References: <>
From: Mario Loffredo <>
Message-ID: <>
Date: Thu, 24 Sep 2020 16:56:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: it
Archived-At: <>
Subject: Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-rdap-sorting-and-paging-17: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Sep 2020 14:59:55 -0000

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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ** 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 --
> 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")

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

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



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