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

Mario Loffredo <> Mon, 27 July 2020 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F9A13A1AAA; Mon, 27 Jul 2020 09:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nNL1gEyicL8k; Mon, 27 Jul 2020 09:41:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 503A53A1B00; Mon, 27 Jul 2020 09:41:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3087260085A; Mon, 27 Jul 2020 18:41:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gqZcDOYnDknq; Mon, 27 Jul 2020 18:41:17 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id AF06D6002F0; Mon, 27 Jul 2020 18:41:17 +0200 (CEST)
From: Mario Loffredo <>
To: David Schinazi <>,
References: <>
Message-ID: <>
Date: Mon, 27 Jul 2020 18:38:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------44568F71F3AB971D7CE456E2"
Content-Language: it
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 16:41:34 -0000

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 ?

> 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?



> _______________________________________________
> regext mailing list

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