[regext] Roman Danyliw's No Objection on draft-ietf-regext-rdap-partial-response-13: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Fri, 04 September 2020 21:13 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CEA3A113C; Fri, 4 Sep 2020 14:13:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-regext-rdap-partial-response@ietf.org, regext-chairs@ietf.org, regext@ietf.org, Jasdip Singh <jasdips@arin.net>, jasdips@arin.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.15.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <159925400198.5399.1992122496217646432@ietfa.amsl.com>
Date: Fri, 04 Sep 2020 14:13:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2K04aU7GNsbG8UQbgUFsHcxAICg>
Subject: [regext] Roman Danyliw's No Objection on draft-ietf-regext-rdap-partial-response-13: (with COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
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, 04 Sep 2020 21:13:28 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-rdap-partial-response-13: 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-partial-response/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 2.1.  Can a server return multiple entries in the availableFieldSets
area with default=TRUE?  Probably not.  Should something be said to that effect?

** Section 4.  Per ‘Fields included in the "brief" and "full" field set
responses MUST take into account the user's access and authorization levels’,
would there be circumstances where the “id” field set should also take into
account the user’s access and authorization level?  Section 8 noted that “RDAP
operators can vary the information returned in RDAP responses based on a
client's access and authorization levels.”  My thinking is that if a given
client’s access level would result in particular fields being removed, then
perhaps they shouldn’t have been listed in the with the “id” field list to
begin with.

** Section 8.

A search query typically requires more server resources (such as
   memory, CPU cycles, and network bandwidth) when compared to a lookup
   query.  This increases the risk of server resource exhaustion and
   subsequent denial of service due to abuse.  This risk can be
   mitigated by supporting the return of partial responses combined with
   other strategies ...

I do not follow how partial responses provide denial of service mitigation when
the attack is intentional.  Wouldn’t the attacker continue to request full
queries given the choice between loading the server with a subset vs. full
query?  Or is this text saying that because of the use of partial responses the
server would have more capacity and this would enable it to better result a
denial service?

** Editorial:
-- Section 1.  Editorial.  s/fewer data/less data/