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

[Alissa Cooper <[e-mail]>]

David, thanks for your review. Mario, thanks for updating the document. I entered a No Objection ballot.

Alissa


> On Jul 27, 2020, at 2:12 PM, David Schinazi <[e-mail]> wrote:
> 
> 
> 
> On Mon, Jul 27, 2020 at 9:41 AM Mario Loffredo <[e-mail] <mailto:[e-mail]>> wrote:
> 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
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq> <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.
> [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:
> 
> 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?
> 
> 
> 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,
> 
> Mario
> 
>> _______________________________________________
>> regext mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/regext <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: [phone]
> Mobile: [phone]
> Web: http://www.iit.cnr.it/mario.loffredo <http://www.iit.cnr.it/mario.loffredo>_______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art