Re: [regext] Opsdir last call review of draft-ietf-regext-rdap-partial-response-13

Mario Loffredo <mario.loffredo@iit.cnr.it> Mon, 17 August 2020 14:05 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 5CD113A0C06; Mon, 17 Aug 2020 07:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, NICE_REPLY_A=-0.949, 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 SBISSWCGmmqs; Mon, 17 Aug 2020 07:05:42 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C6A3A0C4D; Mon, 17 Aug 2020 07:05:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 59C52B803EE; Mon, 17 Aug 2020 16:05:39 +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 3Ocfipauot3G; Mon, 17 Aug 2020 16:05:36 +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 33A08B803E1; Mon, 17 Aug 2020 16:05:36 +0200 (CEST)
To: Joel Jaeggli <joelja@bogus.com>, ops-dir@ietf.org
Cc: last-call@ietf.org, regext@ietf.org, draft-ietf-regext-rdap-partial-response.all@ietf.org
References: <159753180775.5002.17443008189580020542@ietfa.amsl.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <21c3f562-523b-0ba0-3b85-91f373c36dcc@iit.cnr.it>
Date: Mon, 17 Aug 2020 16:02:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <159753180775.5002.17443008189580020542@ietfa.amsl.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/z3mskNMolJZVxmzSKAVZ1HYYNOY>
Subject: Re: [regext] Opsdir last call review of draft-ietf-regext-rdap-partial-response-13
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: Mon, 17 Aug 2020 14:05:44 -0000

Hi Joel,

thanks so much for your review. Please find my comments inline.

Il 16/08/2020 00:50, Joel Jaeggli via Datatracker ha scritto:
> Reviewer: Joel Jaeggli
> Review result: Ready
>
> I have reviewed this document on behalf of the the operations directorate.
>
> This document appears ready.
>
> I would observe that the document describes fairly wide latitude with respect
> to what a server could do with with this facility, yet it's largely posed as
> facility for the client to reduce the data returned to it. A client that is
> authorized asking for less data then it is authorized for poses no real
> challenges however if s the document described one uses authorization level to
> determine what to include in the partial response the implementations need to
> be careful about how the implement such a control to prevent information
> leakage (what fielsd are omitted could tell you significant things about your
> authorization level for example. These server implementation  considerations
> seem outside the scope of this document, and client requests for limited fields
> in a result don't have this property.

The mapping between the content returned and the available field sets 
for the given user profiles should be trasparently described in 
out-of-band documents (e.g. RDAP profiles).

I think the main issue for a server is to return the right information 
according to the user grants but this doesn't depend on whether the 
server implements partial response or not.

What is achieved through this feature is that servers can implement a 
more flexible strategy than returning always the full response, even if 
the full response is tailored on the requestor.

As you rightly stated in your review, some operational aspects (e.g. the 
fields contained in the "brief" response) have been purposefully left 
undefined because the WG considered they should be profile dependent.

Anyway, a non exhaustive list of possible partial response 
implementations are described in "Security Considerations" section.

Hope my response could contribute to shed more light on this document.


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