Re: [Gen-art] [regext] Genart last call review of draft-ietf-regext-rdap-partial-response-12

David Schinazi <> Mon, 27 July 2020 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC49B3A1B71; Mon, 27 Jul 2020 11:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VyDOcQK0l1Oa; Mon, 27 Jul 2020 11:13:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 199553A1B5D; Mon, 27 Jul 2020 11:13:03 -0700 (PDT)
Received: by with SMTP id 140so9523211lfi.5; Mon, 27 Jul 2020 11:13:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DRiQaaBnD6bwGuaapg8YZ7NpxE5gZO6N4lfQ6B11Jx4=; b=DZMuUXP0G1AG1ImZ+yHjTENctSbT0u1qc4ecWWSolE9058TQEWbOUUpJtRKgfUhteN r9MGYp/G6gOfUcnWcBQ+pmC6VvnTE5oQk6V/WWxSjDu/cVYUpJicFrpISoaIDdz46eyr Z07EA8r+x8q19kCIclTljqSX1DLstavCq+fUiQg3TqBgnEoboSP88nRuKaV7F/tAybb1 F2er94w9KXg44CI0WYp65rMpgUpQmlrVMrrxd/PYHUOn2RLUkwjYtQ9hXQ6asBTLCdao +n4Pqz3gXTpY7MpCJo6ZxOSqB0R5PvQ6ycdRuOpEQd+SQ+2j2ce3CBqT9kM8yK6K9qTm +HOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DRiQaaBnD6bwGuaapg8YZ7NpxE5gZO6N4lfQ6B11Jx4=; b=tntG7SjLEzaWS+dWW4hhhUVJvIXpHcMSs4wcG4+2lTu1Poj591T6DzqRnu8UBia567 EW2qS53yA0oxCjyR37/KAgMgBxOV413s4VP2WGKm1wPfo1UpJTbDfG/LqQLiG9f5ZjQz JfLCYoVnxCfOmdcu+OXGmbMIVSn6SPUvHH+h1GWknMh15Av2RaBGaQ7QRwW/GxavurUn h0Y9zdMn4yII6H3bRY9s0REpRUoheJmeoDxssKvPSeiYLWaKHLwE0B1B/QtUukQlixa9 Si2Gxu5f3g7bG3rWSXHnh/LizBpURIEGGUc7Y+n8hPKivwDiCxfc0m38tPxJH7Ojuzs3 KbVw==
X-Gm-Message-State: AOAM532D+aPnX/dOumCzYShXXCL5asOt3NcMt2bkOzzlTFLIq+8EG6sn mB6fc4tm2wPq/qj/DvSi5p+2W1+mAFi7+8cepWeeRg==
X-Google-Smtp-Source: ABdhPJzEXuvtS+RXHfBfvFl47rCtmY/F0Yq67xw/hoD2o0IOsMTskAuZUYdMrU46FkZcB4aWbcqzwm+ipt3pddlJSMw=
X-Received: by 2002:a19:8c9:: with SMTP id 192mr12259705lfi.204.1595873582022; Mon, 27 Jul 2020 11:13:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Mon, 27 Jul 2020 11:12:51 -0700
Message-ID: <>
To: Mario Loffredo <>
Cc: gen-art <>,,,
Content-Type: multipart/alternative; boundary="000000000000f6857005ab704574"
Archived-At: <>
Subject: Re: [Gen-art] [regext] Genart last call review of draft-ietf-regext-rdap-partial-response-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2020 18:13:07 -0000

On Mon, Jul 27, 2020 at 9:41 AM Mario Loffredo <>

> Hi David,
> thanks a lot for your review and feedback. I provide my answer to your
> feedback below:
> Il 25/07/2020 00:47, David Schinazi via Datatracker ha scritto:
> Reviewer: David Schinazi
> Review result: Ready with Issues
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at<> <>.
> Document: draft-ietf-regext-rdap-partial-response-12
> Reviewer: David Schinazi
> Review Date: 2020-07-24
> IETF LC End Date: 2020-08-14
> IESG Telechat date: Not scheduled for a telechat
> Summary: Document is clear, well-written, and short. Thank you!
> Major issues: None
> Minor issues: After reading the document, I was somewhat
> confused as to the definition of fieldSet query parameter.
> I think adding a few sentences to Section 2 explaining that
> a field set is a string that the server generates which maps
> to a set of fields only known to the server would help.
> [ML] It seems to me that both the concepts are already conveyed in the
> document. Maybe they are not adequately clarified.
> The sentence "... whose value is a string identifying a server-defined set
> of supported fields.." means that a field set name and the related list of
> fields are defined by the server.
> With regards to the assumption that a field set is known only by the
> server, this is not generally true.
> Both the field set names and the related list of fields might (hopefully
> should) be shared by as many servers as possible to facilitate
> interoperability as described in section 4.
> Moreover, the field sets together with other server features are expected
> to be described  in out-of-band documents like the RDAP profile.
> Finally, as described in section 2.1, the subsetting_metadata element
> could provide an in-band information about the supported field sets that is
> more reactive to server updates than out-of-band contents.
> Do you think that the concepts above should be furtherly clarified ?

I would say that clarifying this would be useful, because it wasn't clear
to me.
That said, I'm not very knowledgeable about RDAP so maybe I'm not the
target audience.
Though since this document might need to consumed by HTTP server operators
that don't know RDAP either, perhaps a clarification is worth the effort.

> Additionally, specifying that the string can't be empty and
> which characters are allowed might help avoid interop
> issues down the road.
> Nits/editorial comments: None
> [ML] Agreed.
> But rather than updating section 2, I think that it would be better to
> change the section 5 as in the following:
> Each request including an unsupported field set SHOULD produce an
>    HTTP 400 (Bad Request) response code.
> Each request including either an empty or an unsupported "fieldSet" value SHOULD produce an
>    HTTP 400 (Bad Request) response code.
> Is it okay with you?

Yes, this would avoid the interop problem I was worried about.
Though using the word "non-empty" in section 2 wouldn't hurt.
Also, I would personally recommend making this a MUST rather
than a SHOULD so clients can rely on that behavior.


> Mario
> _______________________________________________
> regext mailing listregext@ietf.org
> --
> 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: