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 16:17 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 A0B5A3A1000; Thu, 24 Sep 2020 09:17:31 -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 59ZlEFgbD9vy; Thu, 24 Sep 2020 09:17:29 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) by ietfa.amsl.com (Postfix) with ESMTP id E7CFB3A1068; Thu, 24 Sep 2020 09:17:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 85DDF600688; Thu, 24 Sep 2020 18:17:26 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKdiKu1P87fC; Thu, 24 Sep 2020 18:17:22 +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 30C0560003E; Thu, 24 Sep 2020 18:17:22 +0200 (CEST)
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-regext-rdap-sorting-and-paging@ietf.org" <draft-ietf-regext-rdap-sorting-and-paging@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, Tom Harrison <tomh@apnic.net>
References: <160086803388.29105.12080739329882950467@ietfa.amsl.com> <b237abbb-7567-9070-d0b8-e81b1b63a8ca@iit.cnr.it> <a88b1a3b452a440f8f30cad5e07fe1d6@cert.org>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <a6fd47e6-7c40-7ce7-6c70-b09b2b5627b6@iit.cnr.it>
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: <a88b1a3b452a440f8f30cad5e07fe1d6@cert.org>
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/cazi3htKF1OpPTkiyyixRb9bmfo>
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 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, Mario Il 24/09/2020 17:11, Roman Danyliw ha scritto: > Hi Mario! > >> -----Original Message----- >> From: Mario Loffredo <mario.loffredo@iit.cnr.it> >> Sent: Thursday, September 24, 2020 10:56 AM >> 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> >> 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: +39.0503153497 >> Mobile: +39.3462122240 >> Web: http://www.iit.cnr.it/mario.loffredo -- 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