Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-rdap-sorting-and-paging-17: (with DISCUSS and COMMENT)
Mario Loffredo <mario.loffredo@iit.cnr.it> Thu, 24 September 2020 14:59 UTC
Return-Path: <mario.loffredo@iit.cnr.it>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9603A0E68; Thu, 24 Sep 2020 07:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYcUmlZGPOth; Thu, 24 Sep 2020 07:59:48 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEFE3A0E95; Thu, 24 Sep 2020 07:59:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 1E57EB80378; Thu, 24 Sep 2020 16:59:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m35GOx25rFy9; Thu, 24 Sep 2020 16:59:39 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 8C13DB80375; Thu, 24 Sep 2020 16:59:39 +0200 (CEST)
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-regext-rdap-sorting-and-paging@ietf.org, regext-chairs@ietf.org, regext@ietf.org, Tom Harrison <tomh@apnic.net>
References: <160086803388.29105.12080739329882950467@ietfa.amsl.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <b237abbb-7567-9070-d0b8-e81b1b63a8ca@iit.cnr.it>
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: <160086803388.29105.12080739329882950467@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/-3-OpmwxNmUa7DP35q3IMQoS9NY>
Subject: Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-rdap-sorting-and-paging-17: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=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 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. [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") > > ---------------------------------------------------------------------- > 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: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo
- [regext] Roman Danyliw's Discuss on draft-ietf-re… Roman Danyliw via Datatracker
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Mario Loffredo
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Mario Loffredo