Skip to main content

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

Yes

(Barry Leiba)

No Objection

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

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

Erik Kline
No Objection
Comment (2020-09-20 for -17) Sent
[[ 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.
Murray Kucherawy
No Objection
Comment (2020-09-24 for -17) Sent
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.
Roman Danyliw
(was Discuss) No Objection
Comment (2020-10-02 for -18) Sent for earlier
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) Sent
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 IESG member
Yes
Yes (for -16) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-10-02 for -18) Sent
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 IESG member
No Objection
No Objection (for -17) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (for -17) Not sent