Ballot for draft-ietf-regext-rdap-sorting-and-paging
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
[[ 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.