Subject: [Last-Call] Genart last call review of draft-ietf-regext-rdap-partial-response-12

From: David Schinazi via Datatracker <[email-masked]>
Date: Fri, 24 Jul 2020 15:47:58 -0700

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
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Jul 2020 19:26:09 -0400

Wow, David, thanks for the super-quick review!

Barry

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 27 Jul 2020 18:38:23 +0200

Hi David,

thanks a lot for your review and feedback. I provide my answer to your 
feedback below:

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

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

OLD

Each request including an unsupported field set SHOULD produce an
    HTTP 400 (Bad Request) response code.

NEW

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?

Best,

Mario

> _______________________________________________
> regext mailing list
> [email-masked]
> 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

---

From: David Schinazi <[email-masked]>
Date: Mon, 27 Jul 2020 11:12:51 -0700

On Mon, Jul 27, 2020 at 9:41 AM Mario Loffredo <[email-masked]>
wrote:

> For more information, please see the FAQ at<https://trac.ietf.org/trac/gen/wiki/GenArtfaq> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> 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.
>
> Moreover, the field sets together with other server features are expected
> to be described  in out-of-band documents like the RDAP profile.
>
> could provide an in-band information about the supported field sets that is
> more reactive to server updates than out-of-band contents.
>

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.

>    HTTP 400 (Bad Request) response code.

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.

David

Best,
> regext mailing [email-masked]://www.ietf.org/mailman/listinfo/regext
>
> --
> Dr. Mario Loffredo
> Web: http://www.iit.cnr.it/mario.loffredo
>
>