Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging
draft-ietf-regext-rdap-sorting-and-paging-20

[[ 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.

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.

Thank you for the SECDIR review, Rifaat (Shekh-Yusef)!

Thanks for addressing my DISCUSS and COMMENTs.

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)

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.