Registration Data Access Protocol (RDAP) Partial Response
RFC 8982

Note: This ballot was opened for revision 13 and is now closed.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-09-17 for -15)
Thanks for addressing my Discuss and Comment points!

Erik Kline (was Discuss) No Objection

Martin Duke No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2020-09-07 for -13)
Where is "AvailableFieldSet[]" defined?

I get a Permission Denied error when I click on the link for [REST].  Should it be updated?

I have the same question Roman does about Section 2.1.

I've tried several times, but I can't understand what Section 3 is trying to tell me.

Robert Wilton No Objection

Comment (2020-09-07 for -13)
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

Roman Danyliw No Objection

Comment (2020-09-04 for -13)
** Section 2.1.  Can a server return multiple entries in the availableFieldSets area with default=TRUE?  Probably not.  Should something be said to that effect?

** Section 4.  Per ‘Fields included in the "brief" and "full" field set responses MUST take into account the user's access and authorization levels’, would there be circumstances where the “id” field set should also take into account the user’s access and authorization level?  Section 8 noted that “RDAP operators can vary the information returned in RDAP responses based on a client's access and authorization levels.”  My thinking is that if a given client’s access level would result in particular fields being removed, then perhaps they shouldn’t have been listed in the with the “id” field list to begin with.

** Section 8.

A search query typically requires more server resources (such as
   memory, CPU cycles, and network bandwidth) when compared to a lookup
   query.  This increases the risk of server resource exhaustion and
   subsequent denial of service due to abuse.  This risk can be
   mitigated by supporting the return of partial responses combined with
   other strategies ...

I do not follow how partial responses provide denial of service mitigation when the attack is intentional.  Wouldn’t the attacker continue to request full queries given the choice between loading the server with a subset vs. full query?  Or is this text saying that because of the use of partial responses the server would have more capacity and this would enable it to better result a denial service?

** Editorial:
-- Section 1.  Editorial.  s/fewer data/less data/

Éric Vyncke No Objection

Comment (2020-09-04 for -13)
Thank you for the work put into this document. It is simple to read and appears to address an important problem.

I have only one non blocking comment about section 4, is a "short" response specified in other documents or should it be better described in this document ?

Regards

-éric

(Barry Leiba; former steering group member) Yes

Yes ( for -13)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -13)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -13)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -13)
No email
send info