Re: [regext] Éric Vyncke's No Objection on draft-ietf-regext-rdap-sorting-and-paging-16: (with COMMENT)
Mario Loffredo <mario.loffredo@iit.cnr.it> Fri, 18 September 2020 15:49 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 BDECD3A0EF3; Fri, 18 Sep 2020 08:49:41 -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 FY5UtVy3kKvU; Fri, 18 Sep 2020 08:49:39 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) by ietfa.amsl.com (Postfix) with ESMTP id 38B073A0EEE; Fri, 18 Sep 2020 08:49:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id EC6E1601038; Fri, 18 Sep 2020 17:49:36 +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 3NX2kf18Id9B; Fri, 18 Sep 2020 17:49:34 +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 EAE74600FC3; Fri, 18 Sep 2020 17:49:33 +0200 (CEST)
To: Éric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>
Cc: regext-chairs@ietf.org, tomh@apnic.net, regext@ietf.org, draft-ietf-regext-rdap-sorting-and-paging@ietf.org
References: <160043414369.27718.13984513177906805196@ietfa.amsl.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <1554277d-b5b2-6c09-ff4b-6fc821b3ddec@iit.cnr.it>
Date: Fri, 18 Sep 2020 17:46:18 +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: <160043414369.27718.13984513177906805196@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/C6e7v5w5_yYoFvJa1ZmHkjF0Uz4>
Subject: Re: [regext] Éric Vyncke's No Objection on draft-ietf-regext-rdap-sorting-and-paging-16: (with 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: Fri, 18 Sep 2020 15:49:42 -0000
Hi Eric, thanks a lot for your review. Please find my comments inline. Il 18/09/2020 15:02, Éric Vyncke via Datatracker ha scritto: > Éric Vyncke has entered the following ballot position for > draft-ietf-regext-rdap-sorting-and-paging-16: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below a couple of non-blocking COMMENT points (but, to be honest, I > was close to put a DISCUSS about server performance impact that is not fully > addressed in the security section). > > I hope that this helps to improve the document, [ML] Any feedback is valuable. > > Regards, > > -éric > > == COMMENTS == > > -- Section 2.1 -- > I find the wording a little confusing in ""totalCount": "Numeric" (OPTIONAL) > ... It MUST be provided if and only if ...". While I understand the meaning, > would another wording avoid the conflicting "OPTIONAL" <-> "MUST" ? I.e., the > "OPTIONAL" could possibly be removed. [ML] It's optional because it isn't displayed always and there is only one condition under which it is provided. If one keyword should be changed I think it's more appropriate to replace "MUST with "must" but I would keep both of them. > -- Section 2.2 -- > I am concerned that a server having to compute "totalCount" (even if only to > return the first 10 entries) may spend a lot of time computing this number in > the absence of index... The security section does not offer a definitive answer > to this issue IMHO. E.g., I would prefer to allow the server to refuse to serve > "totalCount" until the last page (and even). [ML] The count operator is optional so a server can support it or not. Moreover, it's reasonable to expect that an RDAP server will rely on some db indexes to efficiently perform searches no matter if it supports counting or not. The purpose of the count operator is just to enable users to immediately know the size of the result set and, consequently, evaluate if the result set is worthy to be scanned. Sometimes, the number of results is itself considered a relevant information. Lastly, there's no need to count the total number of results through a query at each possible result set page because, in general, it doesn't change. Therefore, when an initial query includes the count operator two strategies can be implemented: - the server includes the totalCount value in the first page and doesn't include the count operator in the possible pagination links so the totalCount value is not displayed in the following pages; - the server includes the totalCount value in the first page, encode it in the cursor value and include the count operator in the possible pagination links so that the totalCount value is passed from page to page and always displayed. In both cases, only one counting query is processed. > -- Section 2.3 -- > Is there a reason why RFC 5952 was not used to represent the IPv6 address ? [ML] I apologize. I found this example of conversion from an ipv6 address to a number on the web and I didn't pay attention to the fact that it wasn't compressed. I'll replace it with "2001:0db8:85a3:0:0:8a2e:0370:7334". > > I am concerned that a server having to sort on client-side selection of > properties may have a huge performance impact in the absence of relevant DB > indexes.The security section does not offer a definitive answer to this issue > IMHO. [ML] A server is not required to implement all and only the sorting properties reported in the document. Obviously, an RDAP server is expected to support only those sorting properties which are mapped onto db indexed fields. > > -- Section 2.3.1 -- > Is there a reason for this unusual writing of 'ipV4' (uppercase V) ? [ML] No. It's only a string referencing an RDAP response value. I'll replace it with 'ipv4'. The same for 'ipV6' :-) > > -- Section 2.4 -- > Suggestion: mention that the cursor value is opaque for the client ? [ML] OK > > == NITS == > > -- Section 2.2 -- > Is a 'figure' element really required for a single line example ? [ML] I'll change the figure into text. > > Should the URI be > "https://example.com/rdap/domains?name=*example.com&count=true" (also > applicable to section 2.3) > [ML] I'm not sure to catch your comment. count and sort are two optional query parameters which can be used together or separately. Looking forward for your reply to my comments. Best, Mario > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext -- 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] Éric Vyncke's No Objection on draft-ietf… Éric Vyncke via Datatracker
- Re: [regext] Éric Vyncke's No Objection on draft-… Mario Loffredo
- Re: [regext] Éric Vyncke's No Objection on draft-… Eric Vyncke (evyncke)
- Re: [regext] Éric Vyncke's No Objection on draft-… Mario Loffredo