Skip to main content

Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging
RFC 8977

Yes

(Barry Leiba)

No Objection

Alvaro Retana
Martin Duke
Robert Wilton
Warren Kumari
(Alissa Cooper)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

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

Alvaro Retana No Objection

Erik Kline No Objection

Comment (2020-09-20 for -17)
[[ comments ]]

[ section 2.3 ]

* My current understanding is that it's not possible to request a sort by
  IP address in general (i.e. without regard to IP address family).  Otherwise,
  since some IPv6 addresses (admittedly not any within the current 2000::/3
  GUA space) might be numerically less then some IPv4 addresses, I think there
  would probably need to be some text around relative ordering between IPv4 and
  IPv6 addresses regardless of numerical equivalent values.

  But again: my reading is that sort can only be by ipV4 or ipV6 (and not just
  some generalized "ip" parameter), so this shouldn't be necessary.


[[ nits ]]

[ section 2.1 ]

* s/value of sort "parameter"/value of the "sort" parameter/ perhaps?

[ section 2.4 ]

* I think the cursor value "b2Zmc2V0PTEwMCxsaW1pdD01MAo=" might decode to
  'offset=100,limit=50\n' (with a trailing newline).  The base64 encoding
  without the trailing newline might be 'b2Zmc2V0PTEwMCxsaW1pdD01MA==', but
  someone should double-check me on that.

Martin Duke No Objection

Murray Kucherawy No Objection

Comment (2020-09-24 for -17)
I support Roman's DISCUSS point about resolving the JSONPath reference.  I'm working the chartering of the proposed "jsonpath" working group, so I'm happy to contribute to resolving this.  And a "thank you" to the document shepherd for including this in the writeup.  Another possible option is to cite draft-goessner-dispatch-jsonpath, marking it as "work in progress", though I think that's still tricky because we don't know for sure that changes produced by the proposed working group will be fully backward-compatible with what this document requires.

I also support Ben's DISCUSS point about multi-sorts.

Section 1:

A totally minor nit, but I think the reference to RFC 7230 should be up where HTTP is first used.

Section 2.2:

The ABNF here reminds me that string literals in ABNF are case-insensitive (RFC 5234, Section 2.3).  Just wanted to check that "COUNT=fAlSe" is fine here, for example.

Robert Wilton No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2020-10-02 for -18)
Thank you for the SECDIR review, Rifaat (Shekh-Yusef)!

Thanks for addressing my DISCUSS and COMMENTs.

Warren Kumari No Objection

Éric Vyncke No Objection

Comment (2020-09-18 for -16)
Thank you for the work put into this document. 

Please find below a couple of non-blocking COMMENT points (but, to be honest, I was close to put a DISCUSS about server performance impact that is not fully addressed in the security section).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.1 --
I find the wording a little confusing in ""totalCount": "Numeric" (OPTIONAL) ...  It MUST be provided if and only if ...". While I understand the meaning, would another wording avoid the conflicting "OPTIONAL" <-> "MUST" ? I.e., the "OPTIONAL" could possibly be removed.

-- Section 2.2 --
I am concerned that a server having to compute "totalCount" (even if only to return the first 10 entries) may spend a lot of time computing this number in the absence of index... The security section does not offer a definitive answer to this issue IMHO. E.g., I would prefer to allow the server to refuse to serve "totalCount" until the last page (and even).

-- Section 2.3 --
Is there a reason why RFC 5952 was not used to represent the IPv6 address ?

I am concerned that a server having to sort on client-side selection of properties may have a huge performance impact in the absence of relevant DB indexes.The security section does not offer a definitive answer to this issue IMHO.

-- Section 2.3.1 -- 
Is there a reason for this unusual writing of 'ipV4' (uppercase V) ?

-- Section 2.4 --
Suggestion: mention that the cursor value is opaque for the client ?
      
== NITS ==

-- Section 2.2 --
Is a 'figure' element really required for a single line example ?

Should the URI be "https://example.com/rdap/domains?name=*example.com&count=true" (also applicable to section 2.3)

(Barry Leiba; former steering group member) Yes

Yes (for -16)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -17)

                            

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2020-10-02 for -18)
Thanks for the updates in the -18; they look good with one exception:

In Section 2.4, I strongly recommend using the word "encode" (and "encoding")
instead of "encrypt" (and "encryption") -- it is good to reserve the term "encrypt"
for a procedure that applies cryptographic protection.  Part of why we are
anti-recommending base64 for this usage is because it does not provide cryptographic
protection, so it is surprising to use the word "encrypt" to describe it.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -17)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -17)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -17)