Re: [regext] Second WG LAST CALL: draft-ietf-regext-rdap-reverse-search
Mario Loffredo <mario.loffredo@iit.cnr.it> Mon, 26 September 2022 09: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 9DB9DC14CE2B for <regext@ietfa.amsl.com>; Mon, 26 Sep 2022 02:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3I5CN1169zG for <regext@ietfa.amsl.com>; Mon, 26 Sep 2022 02:49:09 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2F3C14CF15 for <regext@ietf.org>; Mon, 26 Sep 2022 02:49:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id B9FFDB80935; Mon, 26 Sep 2022 11:49:06 +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 nGU_KlLTdemK; Mon, 26 Sep 2022 11:49:03 +0200 (CEST)
Received: from [192.168.16.66] (sa.nic.it [192.12.193.247]) (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 5B468B80931; Mon, 26 Sep 2022 11:49:03 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------oYnqfS958qc89RJr8UBYxO6d"
Message-ID: <e1cf7d56-6cc8-b237-7376-13c9e8844a15@iit.cnr.it>
Date: Mon, 26 Sep 2022 11:46:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
To: Patrick Mevzek <pm@dotandco.com>, regext@ietf.org
References: <07D2C20B-7312-43D5-8D44-F67111C04082@antoin.nl> <f6cfc195-03fb-4359-ad2c-237bc025b188@www.fastmail.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <f6cfc195-03fb-4359-ad2c-237bc025b188@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/DZD2RLOAY2vByrqspyxzmfM3KrE>
Subject: Re: [regext] Second WG LAST CALL: draft-ietf-regext-rdap-reverse-search
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 26 Sep 2022 09:49:13 -0000
Hi Patrick, thanks for your review. Please find my comments inline. Il 25/09/2022 18:21, Patrick Mevzek ha scritto: > On Mon, Sep 12, 2022, at 08:54, Antoin Verschuren wrote: >> Please review this document and indicate your support (a simple “+1” is >> sufficient) or concerns with the publication of this document by >> replying to this message on the list. > I should probably have said something earlier, sorry about this. Better in late than never ;-) > But I have a concern about §6 Implementation Considerations > as I think it glances over far too quickly on very important points. > > I think it can be easy to expect reverse queries to generate "lots" of results, > but then all examples given ("restricting the > search functionality, limiting the rate of search requests according > to the user's authorization, truncating and paging the results, and > returning partial responses.") are not given details, which means there will be left > to implementors and hence multiple incompatible solutions will emerge which will make writing > a client more complex, for any case where it has to span multiple RDAP servers > (and then you are exactly in same territory as EPP extensions, too many of them and too incompatible between them to easily write one client working with all servers). > > There is RFC 8977 "Registration Data Access Protocol (RDAP) Query Parameters for Result > Sorting and Paging" but it is not even referenced from this draft. > Same for RFC 8982 "Registration Data Access Protocol (RDAP) Partial Response", shouldn't > be cited at least as a non-normative reference? Absolutely. Thank you for this remark. Agree that they could be added as informative references. > > - "restricting the search functionality" does that mean by things related to the protocol like constraints on `{searchable-resource-type}` or on `{related-resource-type}` or on `<search-condition>` or by things external to it, like rate-limit? How will a client discover that it got limited for any of those reasons? Do believe that such note can be applied to the RDAP searches in general. That said, each provider can decide to restrict the usage of the query capabilities as he sees fit. One restriction on generic searches could consist in allowing only those partial matching queries including a minimum number of characters before the wildcard. Another one, specific for reverse search, could be to mandate the use of the "role" parameter. The way for servers to signal clients about having issued a search request that cannot be processed is defined in section 4 of RFC 9082, that is, by returning an error. For each of the implemented aforementioned restrictions, the RDAP server can return an error response including information about the reason of the request failure. > - "truncating and paging the results": maybe mention RFC 8977 and 8982 > - "returning partial responses.": RFC 8982? Yes, see my previous comment. > > But how RFC 8982 would apply here since it is not necessarily the client asking for limited > data in return but the server deciding to prune them in content or length? > > Same question in fact for RFC 8977, that starts with client requesting specific subsets and order. Don't see any difference in an RDAP server supporting the operators defined in both RFC8982 and RFC8977 in this specific search rather than in other searches. The benefits for clients from using such operators are common to all of the searches as their implementation supports clients in issuing requests that are less likely to be pruned by the server and obtaining more manageable responses. Hence, they can achieve relevant information in shorter time. Could you please clarify why those operators would be useless specifically here ? > > I also dislike the mention of indexes here because this is specific terminology > of specific technologies and as such I don't believe an RFC describing a protocol > should lay any assumption or give constraints on how implementers decide to implement it. Seems to me that the sentence in question works quite well since the words "indexes and similar functionalities" are used in their common meaning of techniques to speed up the data retrieval. They don't hint at a specific technology. In addition, the sentence is set as a recommendation in order to guide implementers to choose the reverse search properties appropriately. The proposed reverse search properties are generally "indexed" but the document allows the RDAP providers to define additional ones. Anyway, I would have no problem to change that sentence if there was a better way to express the same concept. For example, would it be fine for you If I changed the sentence to the following? To limit the impact of processing the search predicates, servers are RECOMMENDED to make use of techniques to speed up the data retrieval in their underlying data store such as indexes or similar. Best, Mario -- Dr. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web:http://www.iit.cnr.it/mario.loffredo
- [regext] Second WG LAST CALL: draft-ietf-regext-r… Antoin Verschuren
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Jasdip Singh
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Tom Harrison
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Hollenbeck, Scott
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Antoin Verschuren
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Mark Kosters
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Anton Strydom
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Andrew Newton
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Patrick Mevzek
- Re: [regext] Second WG LAST CALL: draft-ietf-rege… Mario Loffredo
- Re: [regext] Extended Second WG LAST CALL: draft-… Antoin Verschuren
- Re: [regext] Extended Second WG LAST CALL: draft-… Antoin Verschuren
- Re: [regext] Extended Second WG LAST CALL: draft-… Patrick Mevzek
- Re: [regext] Extended Second WG LAST CALL: draft-… Tom Harrison
- Re: [regext] Extended Second WG LAST CALL: draft-… Mario Loffredo
- Re: [regext] Extended Second WG LAST CALL: draft-… Antoin Verschuren