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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Mario,


> -----Original Message-----
> From: Mario Loffredo <[e-mail]>
> Sent: 08 September 2020 15:10
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; regext-
> [e-mail]; [e-mail]; Jasdip Singh <[e-mail]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-regext-rdap-
> partial-response-13: (with COMMENT)
> 
> Hi Robert,
> 
> please find my comments below.
> 
> Il 08/09/2020 12:05, Rob Wilton (rwilton) ha scritto:
> > Hi Mario,
> >
> > Please see inline ...
> >
> >> -----Original Message-----
> >> From: iesg <[e-mail]> On Behalf Of Mario Loffredo
> >> Sent: 07 September 2020 18:04
> >> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> >> Cc: [e-mail]; regext-
> >> [e-mail]; [e-mail]; Jasdip Singh <[e-mail]>
> >> Subject: Re: Robert Wilton's No Objection on draft-ietf-regext-rdap-
> >> partial-response-13: (with COMMENT)
> >>
> >> Hi Robert,
> >>
> >> thanks a lot for your review. Please find my comments inline.
> >>
> >> Il 07/09/2020 16:28, Robert Wilton via Datatracker ha scritto:
> >>> 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"?
> >> [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")
> > [RW]
> >
> > Ah, yes.  Thanks for the clarification/explanation.
> >
> >
> >>> 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?
> >> [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".
> > [RW]
> >
> > Yes, I agree that server policy may want to restrict what information is
> returned on the error case.
> >
> >
> >> Definitively, I would keep the fully compliance with the error response
> >> 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."?
> 
> 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?
[RW] 

Works for me.

Thanks for your responsiveness.

Regards,
Rob



> 
> Cheers,
> 
> Mario
> 
> >
> > Regards,
> > Rob
> >
> >
> >>
> >> Looking forward to your reply to my comments.
> >>
> >> Best,
> >>
> >> Mario
> >>
> >>> Regards,
> >>> Rob
> >>>
> >>>
> >>>
> >> --
> >> 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
> 
> --
> 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