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 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0B5A3A1000; Thu, 24 Sep 2020 09:17:31 -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 59ZlEFgbD9vy; Thu, 24 Sep 2020 09:17:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E7CFB3A1068; Thu, 24 Sep 2020 09:17:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85DDF600688; Thu, 24 Sep 2020 18:17:26 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nKdiKu1P87fC; Thu, 24 Sep 2020 18:17:22 +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 30C0560003E; Thu, 24 Sep 2020 18:17:22 +0200 (CEST)
To: Roman Danyliw <>, The IESG <>
Cc: "" <>, "" <>, "" <>, Tom Harrison <>
References: <> <> <>
From: Mario Loffredo <>
Message-ID: <>
Date: Thu, 24 Sep 2020 18:14:03 +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 16:17:32 -0000

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,


Il 24/09/2020 17:11, Roman Danyliw ha scritto:
> Hi Mario!
>> -----Original Message-----
>> From: Mario Loffredo <>
>> Sent: Thursday, September 24, 2020 10:56 AM
>> To: Roman Danyliw <>; The IESG <>
>> Cc:;;
>>; Tom Harrison <>
>> 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
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> The document, along with other ballot positions, can be found here:
>>> ging/
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> ** 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")
> Both of these proposed edits work for me.  Thanks.
> Regards,
> Roman
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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.
>> 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:

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