Subject: [regext] Éric Vyncke's No Objection on draft-ietf-regext-rdap-sorting-and-paging-16: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 18 Sep 2020 06:02:23 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-regext-rdap-sorting-and-paging-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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)

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 18 Sep 2020 17:46:18 +0200

Hi Eric,

thanks a lot for your review. Please find my comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
[ML] Any feedback is valuable.
> "OPTIONAL" could possibly be removed.
[ML] It's optional because it isn't displayed always and there is only 
one condition under which it is provided. If one keyword should be 
changed I think it's more appropriate to replace "MUST with "must" but I 
would keep both of them.
> "totalCount" until the last page (and even).

[ML] The count operator is optional so a server can support it or not. 
Moreover, it's reasonable to expect that an RDAP server will rely on 
some db indexes to efficiently perform searches no matter if it supports 
counting or not.

The purpose of the count operator is just to enable users to immediately 
know the size of the result set and, consequently, evaluate if the 
result set is worthy to be scanned. Sometimes, the number of results is 
itself considered a relevant information.

Lastly, there's no need to count the total number of results through a 
query at each possible result set page because, in general,  it doesn't 
change. Therefore, when an initial query includes the count operator two 
strategies can be implemented:

- the server includes the totalCount value in the first page and doesn't 
include the count operator in the possible pagination links so the 
totalCount value is not displayed in the following pages;

- the server includes the totalCount value in the first page, encode it 
in the cursor value and include the count operator in the possible 
pagination links so that the totalCount value is passed from page to 
page and always displayed.

In both cases, only one counting query is processed.

> Is there a reason why RFC 5952 was not used to represent the IPv6 address ?
[ML] I apologize. I found this example of conversion from an ipv6 
address to a number on the web and I didn't pay attention to the fact 
that it wasn't compressed. I'll replace it with 
"2001:0db8:85a3:0:0:8a2e:0370:7334".
> indexes.The security section does not offer a definitive answer to this issue
[ML] A server is not required to implement all and only the sorting 
properties reported in the document. Obviously, an RDAP server is 
expected to support only those sorting properties which are mapped onto 
db indexed fields.
> Is there a reason for this unusual writing of 'ipV4' (uppercase V) ?
[ML] No. It's only a string referencing an RDAP response value. I'll 
replace it with 'ipv4'. The same for 'ipV6' :-)
> Suggestion: mention that the cursor value is opaque for the client ?
[ML] OK
> Is a 'figure' element really required for a single line example ?
[ML] I'll change the figure into text.
> applicable to section 2.3)
[ML] I'm not sure to catch your comment. count and sort are two optional 
query parameters which can be used together or separately.

Looking forward for your reply to my comments.

Best,

Mario

>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 22 Sep 2020 13:45:04 +0000

Mario

It seems that I forgot to press SEND on this one ;-)

First thank you for your reply

Look for EV> below (I have removed a couple of parts where we are all in agreement)

-éric

Hi Eric,

EV> While I fully understand the use of totalCount (as explained below), the server should be able to refuse to serve this totalCount in the case of non-existing index. There are also indexes that are not really useful to count: e.g., in SQL ‘col LIKE “%foo%” will require a parsing of all rows.

EV> I am afraid that while I was reading of the document, I failed to spot this specific list of properties as the bare minimum and having the possibility for the server to refuse to serve a filtering based on some properties.

EV> simply to use the documentation/examples domains both in the host and in the query 😉

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 22 Sep 2020 17:03:26 +0200

Hi Eric,

plase find my comments below.

Il 22/09/2020 15:45, Eric Vyncke (evyncke) ha scritto:
> EV> While I fully understand the use of totalCount (as explained 
> below), the server should be able to refuse to serve this totalCount 
> in the case of non-existing index. There are also indexes that are not 
> really useful to count: e.g., in SQL ‘col LIKE “%foo%” will require a 
> parsing of all rows.
>
[ML] Absolutely but, in general, if the server allows the selection of a 
result set, it can allow results count as well. Regarding your example, 
servers are obviously not recommended to support a wildcard prefixed 
search pattern no matter if the count operator is requested. Conversely, 
if a server support this kind of search, it can allow counting because, 
in any case, a SQL select count takes much less time than a SQL select.
> EV> I am afraid that while I was reading of the document, I failed to 
> spot this specific list of properties as the bare minimum and having 
> the possibility for the server to refuse to serve a filtering based on 
> some properties.
>
>
[ML]  The sorting properties included in the document are those which 
are more likely to be supported. They are listed in the document just to 
improve the interoperability between clients and servers. They are not 
required and, most probably, they aren't the only ones.
> EV> simply to use the documentation/examples domains both in the host 
[ML] Undestood. I'll uniform the queries. Moreover, to make the examples 
more realistic, I'll change all the prefixed wildcard patterns into 
suffixed wildcard patterns.

Best,

Mario