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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 07 Sep 2020 07:28:29 -0700

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

Hi,

Thank you for this document.  I have two minor comments:

2.1.2.  Representing Subsetting Links

           "value": "https://example.com/rdap/domains?name=*nr.com
                     &fieldSet=afieldset",

Should "afieldset" be "anotherfieldset"?

5.  Negative Answers

   Each request including an empty or unsupported "fieldSet" value MUST
   produce an HTTP 400 (Bad Request) response code.  Optionally, the
   response MAY include additional information regarding the negative
   answer in the HTTP entity body.

Given the solution suggests that subsetting metadata may be included in
positive responses, it might be helpful to also include similar metadata in
negative responses.  I.e. rather than just stating that a fieldSet is invalid,
perhaps there should be a recommendation that the response include the list of
possible valid values that fieldSet may take?

Regards,
Rob

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 7 Sep 2020 19:04:01 +0200

Hi Robert,

thanks a lot for your review. Please find my comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/

[ML] In web linking (RFC8288), the "value" field contains the context 
URI and the "target" field contains the target URI in a given relation 
with the context URI.

In Figure 2, the context URI is the current view of the results provided 
according to the current field set (i.e. "afieldset") while the target 
URI is an alternative view provided according another field set (i.e. 
"anotherieldset")

> possible valid values that fieldSet may take?

[ML] I think this pertains to the server policy. RDAP (RFC7483) allows 
producers to provide consumers with additional information in error 
responses through "notices" and "notices" can include "links".

Definitively, I would keep the fully compliance with the error response 
structure defined in RFC7483.

Looking forward to your reply to my comments.

Best,

Mario

-- 
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: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 8 Sep 2020 10:05:27 +0000

Hi Mario,

Please see inline ...

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Mario Loffredo
> Sent: 07 September 2020 18:04
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; regext-
> [email-masked]; [email-masked]; Jasdip Singh <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-regext-rdap-
> partial-response-13: (with COMMENT)
> 
> Hi Robert,
> 
[RW] 

Ah, yes.  Thanks for the clarification/explanation.

> responses through "notices" and "notices" can include "links".
[RW] 

Yes, I agree that server policy may want to restrict what information is returned on the error case.

> structure defined in RFC7483.
[RW] 

Okay.  I agree that having the structure conform to RFC7843 makes sense.

I was sort of thinking of something more like section 6 from RFC 7483.  E.g., the text could provide an example error response something like:

   {
     "errorCode": 400,
     "title": "FieldSet 'unknown-fieldset' is not a valid FieldSet" 
     "description":
     [
       "Supported FieldSet values are 'a-valid-fieldset' and 'another-valid-fieldset'."
     ]
   }

Probably this should only be returned if the request was otherwise valid.

And, I agree that the server could also choose to return valid links as part of notices.

Do you think that it would be helpful for the document to elaborate beyond "Optionally, the response MAY include additional information regarding the negative answer in the HTTP entity body."?

Regards,
Rob

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 8 Sep 2020 16:09:36 +0200

Hi Robert,

please find my comments below.

> Do you think that it would be helpful for the document to elaborate beyond "Optionally, the response MAY include additional information regarding the negative answer in the HTTP entity body."?

OK. I would write:

"Optionally, the response MAY include additional information regarding the supported fieldSet values in the HTTP entity body."

Besides, I can include something similar to your example as  an example 
error response.

Does it works for you?

Cheers,

Mario

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 8 Sep 2020 14:17:44 +0000

Hi Mario,

> From: Mario Loffredo <[email-masked]>
> Sent: 08 September 2020 15:10
> >>> positive responses, it might be helpful to also include similar
> metadata
> >> in
> > I was sort of thinking of something more like section 6 from RFC 7483.
> E.g., the text could provide an example error response something like:
> >
> >     {
> >       "errorCode": 400,
> > Do you think that it would be helpful for the document to elaborate
> beyond "Optionally, the response MAY include additional information
> regarding the negative answer in the HTTP entity body."?
> 
> OK. I would write:
> 
> "Optionally, the response MAY include additional information regarding the
> supported fieldSet values in the HTTP entity body."
> 
[RW] 

Works for me.

Thanks for your responsiveness.

Regards,
Rob