Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-rdap-sorting-and-paging-17: (with DISCUSS and COMMENT)

Hi Mario,

Not a whole lot left to say, but what there is is inline.

On Wed, Sep 30, 2020 at 01:28:53PM +0200, Mario Loffredo wrote:
> Hi Ben,
> 
> thanks a loto for uor quick reply to my responses. My comments are inline.
> 
> Il 29/09/2020 02:14, Benjamin Kaduk ha scritto:
> > Hi Mario,
> >
> > Also inline.
> >
> > On Sat, Sep 26, 2020 at 03:56:03PM +0200, Mario Loffredo wrote:
> >> Hi Benjamin,
> >>
> >> thanks a lot for your extensive review. I apologize for the delay in
> >> replying but I have been very busy the last two days and your feedback
> >> is very detailed.
> >>
> >> Please find my coments inline.
> >>
> >> Il 23/09/2020 23:40, Benjamin Kaduk via Datatracker ha scritto:
> >>> Benjamin Kaduk has entered the following ballot position for
> >>> draft-ietf-regext-rdap-sorting-and-paging-17: Discuss
> >>>
> >>> 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/
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Should we say something about which order the sorting criteria are
> >>> applied (first to last vs last to first) when multiple sortItems are
> >>> specified in a query?
> >> [ML] The common interpretation is from left to right so I don't think we
> >> need to clarify this concept.
> > I think I can accept not saying more on this subject, but I am curious:
> > when you say left to right, that means that the leftmost parameter is
> > higher priority?  So that, to give a totally contrived example, if I had
> > pairs of (name, id), a query with &sort=name;&sort=id; would give:
> >
> > ("alpha", 10)
> > ("alpha", 20)
> > ("beta", 10)
> > ("beta", 20)
> 
> [ML]  Exactly.
> 
> One minor comments: the right notation would be &sort=name,id

This is what I get for writing email without consulting the document;
thanks for spotting it.

> >
> >>> I recognize that in the HATEOS model, the actual JSONPaths reported by
> >>> the server should be used by the client to determine what a given sort
> >>> property does, but it also seems like it would be confusing for this
> >>> document to specify (e.g.) an "email" property with specific JSONPath,
> >>> and then have a server go off and use "email" to mean something else,
> >>> even if that is just the addition of "pref" as discussed at the end of
> >>> Section 2.3.1.  Do we want to try to have the properties defined by this
> >>> document be universally defined and encourage the use of new/different
> >>> property names for variations on them?  (The answer may well be "no",
> >>> but the answer is not intuitively clear to me.)  To put it another way,
> >>> is the list in Section 2.3.1 normative, or just an example?
> >> [ML] I would say "normative" just to facilitate interoperability and
> >> avoid ambiguities. Maybe it could be enough to say that the sorting
> >> properties deifined in the document are considered reserved so an RDAP
> >> server MUST not map them onto other RDAP response values.
> >>
> >> Does it work for you?
> > Yes, that would work for me.  Thanks!
> [ML] Perfect.
> >
> >>> ----------------------------------------------------------------------
> >>> COMMENT:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Section 1
> >>>
> >>>      However, there are some drawbacks associated with the use of the HTTP
> >>>      header.  First, the header properties cannot be set directly from a
> >>>      web browser.  Moreover, in an HTTP session, the information on the
> >>>      status (i.e. the session identifier) is usually inserted in the
> >>>      header or a cookie, while the information on the resource
> >>>      identification or the search type is included in the query string.
> >>>      The second approach is therefore not compliant with the HTTP standard
> >>>      [RFC7230].  As a result, this document describes a specification
> >>>      based on the use of query parameters.
> >>>
> >>> A few more words (section number from 7230?) on why the second approach
> >>> is not compliant with HTTP might help the reader, though it isn't
> >>> stricly necessary (we're not using it, after all).
> >> [ML] Could it be better to replace RFC7230 with RFC7231 and put a
> >> refernce to Section 8.3.1
> >> (https://tools.ietf.org/html/rfc7231#section-8.3.1) ?
> > It might be, but I think I still don't understand why using the HTTP header
> > field for sorting and paging information is not compliant with HTTP -- the
> > linked section says that header fields can be used to communicate
> > information about the target resource, which IIUC includes the resource as
> > qualified by the query string.  (But note that I am not an HTTP expert...)
> 
> [ML]  Would it be more appropriate to update the sentence as in the 
> following?
> 
> OLD
> 
> The second approach is therefore not compliant with the HTTP standard 
> [RFC7230]
> 
> NEW
> 
> The second approach is therefore not compliant with the most common 
> practices about the usage of the HTTP headers [RFC7231]

That's better, though it does not help the reader find out what those
"common practices" are.  (It suffices to justify the choice, though, so I
won't press the point further.)

> >>> Section 2.1
> >>>
> >>>         *  "jsonPath": "String" (OPTIONAL) the JSONPath of the RDAP field
> >>>            corresponding to the property;
> >>>
> >>> What is this path relative to?  (Does the client have to know from the
> >>> other context what type of object it refers to?)
> >> [ML]  All the JSONPath expressions defined in the document are relative
> >> to the root of an RDAP response.  The sorting_metadata object is
> >> included in the same response so I think that the context is clear and
> >> no further clarification is needed.
> > Now that you mention it, I do recall other discussion of paths being
> > relative to the root; my apologies for the noise.
> [ML] You are welcome.
> >
> >>>         *  "links": "Link[]" (OPTIONAL) an array of links as described in
> >>>            [RFC8288] containing the query string that applies the sort
> >>>            criterion.
> >>>
> >>> Just to check: this is going to have the same structure for a Link
> >>> object that draft-ietf-regext-rdap-partial-response does?  (I am not
> >>> coming up with a great way to deduplicate the definitions, off the top
> >>> of my head.)
> >> [ML] Yes. The sorting links have the same structure as the subsetting
> >> links (see Section 2.3.2.).
> >>>      o  "pageSize": "Numeric" (OPTIONAL) a numeric value representing the
> >>>         number of objects returned in the current page.  It MUST be
> >>>         provided if and only if the total number of objects exceeds the
> >>>         page size.  This property is redundant for RDAP clients because
> >>>         the page size can be derived from the length of the search results
> >>>         array but, it can be helpful if the end user interacts with the
> >>>         server through a web browser;
> >>>
> >>> If it's redundant, we should probably say something about error handling
> >>> for when the things that are supposed to be identical have different
> >>> values.
> >> [ML]  I think this situation is very unlinkely.  Anyway, in this case,
> >> the length of the results array really counts. Obviously, it is a bit
> >> more likely that the totalCount value might be different from the sum
> >> of  the number of results in each page. In fact, even if the
> >> registration data can't be considered real-time data, it might happen
> >> that the count parameter is present in the initial query and it might
> >> take time to scroll the result set, so there could be a small likelihood
> >> that the initial totalCount value is obsolete because the result set is
> >> changed in the meantime. Also in this case, the sum of each result array
> >> length really counts.
> >>
> >> Should I write something about?
> > Thanks for the additional explanation.  I think that if we were to write
> > anything more, it would just be a few words in the description here to
> > indicate that it's just for convenience, e.g., "representing the number of
> > objects that should have been returned in the current page".  But it is
> > probably okay to leave it unchanged, too.
> [ML] Changed.
> >>> Section 2.3
> >>>
> >>>      Except for sorting IP addresses, servers MUST implement sorting
> >>>      according to the JSON value type of the RDAP field the sorting
> >>>      property refers to.  That is, JSON strings MUST be sorted
> >>>      lexicographically and JSON numbers MUST be sorted numerically.  If IP
> >>>      addresses are represented as JSON strings, they MUST be sorted based
> >>>      on their numeric conversion.
> >>>
> >>> There are more JSON types than string and number; are those other types
> >>> garanteed to not appear in sortable RDAP fields?  (I can't see how such
> >>> a guarantee could be made, given that servers can define their own
> >>> sorting properties.)
> >> [ML] The other primitive JSON type remaining is boolean but I don't
> >> think it makes sense to sort by a boolean property. Instead, I missed
> > I think I also had JSON maps in mind, but I guess it is not exactly defined
> > to sort by a map itself, only a primitive type, so my question was a bit
> > silly.
> [ML] Yes. Only values with primitive types.
> >> that those values denoting dates and times MUST be sorted in
> >> chronological order even if they are strings. I'll update the sentence
> >> as in the following:
> >>
> >> Except for sorting IP addresses and values denoting dates and times, servers MUST implement sorting
> >>      according to the JSON value type of the RDAP field the sorting
> >>      property refers to.  That is, JSON strings MUST be sorted
> >>      lexicographically and JSON numbers MUST be sorted numerically.
> >>      Values denoting dates and times MUST be sorted in chronological order.  If IP
> >>      addresses are represented as JSON strings, they MUST be sorted based
> >>      on their numeric conversion.
> >>
> >> Does it work for you?
> > I think so; thanks.
> [ML] Good.
> >
> >>>      If the "sort" parameter reports an allowed sorting property, it MUST
> >>>      be provided in the "currentSort" field of the "sorting_metadata"
> >>>      element.
> >>>
> >>> nit: is "reports" the best word to describe this behavior (which, IIUC,
> >>> is "present in the query component of the request URL"?
> >> [ML] Sounds better.
> >>> Section 2.3.1
> >>>
> >>>      In the "sort" parameter ABNF syntax, property-ref represents a
> >>>      reference to a property of an RDAP object.  Such a reference could be
> >>>      expressed by using a JSONPath.  The JSONPath in a JSON document
> >>>
> >>> nit: is there a missing word here ("a JSONPath expression")?
> >> [ML] Just for coinciseness, may I use "jsonpath" to mean "JSONPath
> >> expression" and keep "JSONPath" to refer to the specification?
> >>
> >> I could write something like: "JSONPath expression (named "jsonpath" in
> >> the following)"
> > That's fine from my perspective, sure.
> [ML] Perfect.
> >
> >>>      o  Note that some of the object specific properties are also defined
> >>>         as query paths.  The object specific properties include:
> >>>
> >>> nit: the list structure in this item does not seem parallel to the
> >>> structure of the first item.
> >> [ML] OK. I'll change the sentence as in the following:
> >>
> >> Object specific properties.  Note that some of these properties
> >>         are also defined as query paths.  These properties include:
> >>
> >>>         as two representations of the same value.  By default, the
> >>>         unicodeName value MUST be used while sorting.  When the
> >>>         unicodeName is unavailable, the value of the ldhName MUST be used
> >>>         instead;
> >>>
> >>> I'm not entirely sure how much value "by default" adds here.  Would the
> >>> meaning be different if we said "The unicodeName value MUST be used
> >>> while sorting if it is present; when the unicodeName is unavailable, the
> >>> value of the ldhName is used instead"?
> >> [ML] No, it wouldn't. I'll change the sentence as you suggest.
> >>>      o  The jCard "sort-as" parameter MUST be ignored for the sorting
> >>>         capability described in this document;
> >>>
> >>> It's a little bit of a juxtaposition to refer to jCard here in the prose
> >>> but vcard in the table.
> >> [ML] I would keep it as is. Instead, I would replace all the "vcard"
> >> occurrences with "jCard". Being jCard a transliteration of vCard in
> >> JSON, it seems appropriate to me to keep the references to RFC6350
> >> sections and  to use the corresponding jCard elements for the mapping
> >> between the sorting properties and the RDAP response elements. Besides,
> >> I would write a sentence about the fact that jCard is the JSON format of
> >> vCard, add a link to RFC7095 and insert RFC7095 among the Normative
> >> References.
> >>
> >> Do you agree?
> > Yes, thanks.
> [ML] OK.
> >
> >>>      o  Even if a nameserver can have multiple IPv4 and IPv6 addresses,
> >>>         the most common configuration includes one address for each IP
> >>>         version.  Therefore, the assumption of having a single IPv4 and/or
> >>>         IPv6 value for a nameserver cannot be considered too stringent.
> >>>
> >>> I disagree with the flat assertion that it "cannot be considered too
> >>> stringent".  It can be so considered, as a matter of difference of
> >>> opinion; what is appropriate to do here is to say that this
> >>> document/protocol makes the assumption (especially since we go on to
> >>> describe the exception-handling procedure when the assumption is
> >>> violated).
> >> [ML] May I udpate that sentence as in the following?
> >>
> >> OLD
> >>
> >> Therefore, the assumption of having a single IPv4 and/or
> >>         IPv6 value for a nameserver cannot be considered too stringent.
> >>
> >> NEW
> >>
> >> Therefore, this specification makes the assumption that nameservers have a single IPv4 and/or
> >>         IPv6 value.
> > Yes, please!
> [ML] Done.
> >
> >>>      o  Multiple events with a given action on an object might be
> >>>         returned.  If this occurs, sorting MUST be applied to the most
> >>>         recent event;
> >>>
> >>> This makes a lot of sense as the default and I don't propose changing it
> >>> now, but I do wonder how hard it would be to add support later for
> >>> sorting on (say) the oldest event instead.
> >> [ML] Well, I wrote that sentence because some RDAP events can appear
> >> multiple times. For example, a domain might be locked-unlocked
> >> repeatedly. The purpose of that sentence is just to avoid ambiguities
> >> and implicitly suggest RDAP providers to arrange events with the same
> >> type in descending chronological order.
> >>>      The "jsonPath" field in the "sorting_metadata" element is used to
> >>>      clarify the RDAP field the sorting property refers to.  The mapping
> >>>      between the sorting properties and the JSONPaths of the RDAP fields
> >>>      is shown below:
> >>>      [...]
> >>>         name
> >>>
> >>>            $.domainSearchResults[*].unicodeName
> >>>
> >>> This seems to ignore the subtlety regarding unicodeName vs ldhName.  Is
> >>> there a way it could be expressed in JSONPath?
> >> [ML] If unicodeName and ldhName were alternative, the JSONPath union
> >> operator would fit (i.e.
> >> $.domainSearchResults[*].[unicodeName,ldhName]). Currently, RFC7483
> >> contains no assumption about when they should/must be present but
> >> examples seem to recommend to present unicodeName only for IDNs. When
> >> both the properties are present, the union operator doesn't fit exactly
> >> and I haven't still found the right JSONPath expression based only on
> >> the basic operators. However, since the "jsonPath" member is only for
> >> documentation, the aforesaid JSONPath expression could be the most
> >> suitable for conveying that sorting is applied on a kind of
> >> <unicodeName, ldhName> combination.
> > I have to defer to your expertise here; thank you for thinking about it.
> [ML] Thanks. Maybe this is the only case where the JSONPath WG outcomes 
> might be helpful :-)
> >
> >>>      o  Nameserver
> >>>
> >>>         name
> >>>
> >>>            $.domainSearchResults[*].unicodeName
> >>>
> >>> Presumably this is supposed to be nameserverSearchResults?
> >> [ML] Absolutely. It's a cut-and-paste typo :-)
> >>> Section 2.4
> >>>
> >>> I think we want another introductory paragraph like:
> >>>
> >>> % The cursor parameter is used by the server to preserve information
> >>> % about the pagination state of a given query's results across calls to
> >>> % the search API, so that successive requests by the client can return
> >>> % page N, N+1, N+2, etc.  Its value is only required to be interpretable
> >>> % by the server and could be implemented, for example, as an opaque
> >>> % database lookup key.  If a server does use a method for generating
> >>> % cursor values that involves internal structure, such as the one
> >>> % described below, the server needs to recognize that the value supplied
> >>> % by a client could have been modified (maliciously), and implement
> >>> % appropriate bounds-checking and similar measures when parsing received
> >>> % values.
> >>>
> >>> The current wording strongly suggests that base64-encoding a meaningful
> >>> value that the client could inspect or even construct is required, and I
> >>> do not think that is very maintainable or what was intended, given the
> >>> current second paragraph ("servers can change the method over time
> >>> without announcing anything to clients").
> >>>
> >>> (side note) I'm also pretty partial to the way JMAP discusses returning
> >>> (paginated, but non-uniformly) changes to a given data stream, e.g., at
> >>> https://www.rfc-editor.org/rfc/rfc8620.html#section-5.2 -- any given
> >>> state is named, and you can get "stuff starting at <named state>" and
> >>> the name to use for the state as of the current reply.
> >> [ML] Maybe I didn't make myself clear.
> >>
> >> The Base64 encoding is a simple (unrecommended) trasformation to make
> >> the cursor value opaque to the client. It just seemed suitable to me for
> >> being used in some examples.But if you take a loook at the example of
> >> Figure 6, you may note that you can't obtain a meaningful result by
> >> simply Base64-decoding the cursor value. Definitively, the method to
> >> encrypt the cursor value must be more complex than a mere Base64 encoding.
> >>
> >> Regarding the sentence between brackets, it means that servers can
> >> change the underlying pagination strategy without having an impact on
> >> clients. A server can initially implement the offset pagination and then
> >> turns to the keyset pagination but this has no effect on clients' features.
> >>
> >> The same concepts about the checks that servers should make in order to
> >> check the cursor value are reported both in the "Negative Answer"
> >> section and in Appedix C.3. "Paging"
> >>
> >> Anyway, I'll try to integrate your text in the current document and add
> >> a sentence with the purpose of discouraging the use of the
> >> Base64-encoding in the cursor implementations.
> > Thank you; I did not know that you wanted to discourage the use of plain
> > base64 encoding, but that is reassuring to know.
> > (I did notice that the example in Figure 6 did not decode to a meaningful
> > result, but did not make much of a conclusion from that.)
> [ML] OK. I will add some text to clarify that a mere Base64 encoding is 
> not recommended to encrypt the cursor value.

Okay, thank you.

> >
> >>> Section 4
> >>>
> >>> If the server doesn't have access to an efficient (e.g.) counting
> >>> operation on the backend, would we recommend that the server not support
> >>> sorting/pagination, since there's not much benefit from having the
> >>> server pull up all the results and count them just to be able to return
> >>> the total count value back to the client, and then go do the same work again
> >>> when the client asks for the next page of results?
> >> [ML] In my implementation the RDAP server doesn't present the count
> >> operator in the sorting and paging links. The number of results doesn't
> >> change at all if the result set is sorted by a property rather than
> >> another. The same generally occurs (as I wrote above) if the client is
> >> scrolling the result set pages. So why to repeat the count parameter in
> >> the links? The totalCount value is returned in the response to the
> >> initial query and, as It is no more repeated in the links,  the counting
> >> operation is not executed. Therefore, we don't need to make particular
> >> assumptions about the performance of counting operation.
> >>> Section 7
> >>>
> >>> I suggest noting that (encoded) structured "cursor" values present a new
> >>> attack surface on the server that needs to be protected.
> >> [ML] Sorry, could you futherly explain this concept? AFAIK, it is
> >> possible to protect REST API endpoints but not query parameters.
> > I think this was assuming that the server was going to just base64-encode
> > something like "offset=100,limit=50" -- in that case a client could pass in
> > the base64'd version of "offset=1000000000,limit=50".  The server would
> > need to sanity-check the results of base64 decoding and reject the
> > too-large offset.  If the server is expecting to do a fancier
> > self-encrypted-token scheme for the cursor, the integrity check associated
> > with the encryption takes care of this protection inherently, and we may
> > not need to mention anything about sanitizing these valuess..
> [ML] OK.
> >
> >>>      results in a response.  However, this last security policy can result
> >>>      in a higher inefficiency if the RDAP server does not provide any
> >>>      functionality to return the truncated results.
> >>>
> >>> I'm not sure I understand (or agree with) this last sentence -- it seems
> >>> that unlateral silent truncation of results by the server leads to not
> >>> just inefficiency but also potential security considerations in its own
> >>> right, with the client not knowing that it has incomplete results.
> >>> Also, if the server is truncating the results, by definition it "has
> >>> functionality to return the truncated results" -- that's what it's
> >>> doing!  So I assume the intent was to say something about negotiating or
> >>> indicating that the results are truncated, not actually doing the
> >>> truncation.
> >> [ML] I think that servers legitimately truncate the result sets to
> >> mitigate the risk of resource exhaustion and consequent denial of
> >> service. The implementation of the capablities described in this
> >> document makes servers to keep on managing sustainable result sets and,
> >> at the same time, increases clients'possibility to avoid truncation and
> >> find relevant results.
> > I agree with the paragraph you just wrote.  However, I think that the state
> > of affairs prior to this document, with unilateral truncation by the
> > server, can lead not just to "inefficiency" but also to security risks.  So
> > I was hoping to see something like "can result in higher inefficiency or
> > risk due to acting on incomplete information".
> [ML] OK. I will change the sentence as you suggest.
> > My second point ("Also, if the server [...]") was intending to suggest that
> > the last sentence say something like "if the RDAP Server does not provide
> > any functionality to return sorted results or iterate through the full
> > result set".
> 
> [ML] You are right. I mispelled the sentence. Is it fine for you if I 
> change the sentence as in the follwing?
> 
> OLD
> 
> if the RDAP server does not provide any
>      functionality to return the truncated results
> 
> NEW
> 
> if the RDAP server does not provide any
>      functionality to return results removed by truncation

Yes, perfect!

> >
> >>>      The new parameters presented in this document provide RDAP operators
> >>>      with a way to implement a server that reduces inefficiency risks.
> >>>
> >>> [same question about "inefficiency" being the right word]
> >> [ML] Maybe I can replace the phrase "that reduces inefficiency risks."
> >> with the phrase "that reduces the risk of resource exhaustion and
> >> consequent denial of service".
> >>
> >> Are you ok with it?
> > Denial of service is only one of the risks I have in mind; another is that
> > if a server silently truncates, a client will have incomplete data and
> > might derive a conclusion ("domain X does not satisfy property Y") that is
> > fal
> [ML] OK. As I wrote above, I'll change the sentence to outline the risk 
> due to acting on incomplete information.
> > se.
> >
> >>> Appendix B
> >>>
> >>>      o  It does not allow direct navigation to arbitrary pages because the
> >>>         result set must be scrolled in sequential order starting from the
> >>>         initial page;
> >>>
> >>> (side note) I didn't follow the references, so maybe this was covered
> >>> there, but I don't quite follow why direct navigation is impossible.  If
> >>> you use a key field for seeking, can't you just start in the middle from
> >>> some known value for that key field?
> >> [ML]  Especially when you know the total counf of a result set,  you can
> >> directly jump to a specific point in the result set through offset
> >> pagination but you can't do the same through keyset pagination because
> >> you don't know the key value at that point in advance. One can wonder:
> >> what jumping in the result set is use for? Well, for example, if you are
> >> looking for a specific item in a ordered collection of items, you could
> >> find it through the quicksort algorithm.
> > I don't want to press this topic very much, so let me just try a brief
> > example.  Suppose I have a sorted set of ASCII strings, and I want to see if the
> > string "koala" is present.  I could start at the beginning and look at each
> > one in turn until I get to something that sorts after "koala", or I could
> > ask the database "give me the first thing you have that is after "k", which
> > gets me some of the say there.  Is the problem that you need an actual
> > value in the dataset to start from, and since "k" isn't guaranteed to be in
> > the set you are forced to start from the beginning?
> 
> [ML] Offset pagination is based on the positions of the results within 
> the result set while keyset pagination is based on a unique combination 
> of values of the results. You can always skip the first K results of a 
> result set by specifying offset=K but you can't do the same through 
> keyset pagination because you don't know what is the combination of 
> values placed at position K.
> 
> Let me give you an example that can clarify.
> 
> Let's suppose that the query "k*" returns N=1000 results and the length 
> of result page is 100. The fastest method to find if "koala" is present 
> is to jump to the middle (i.e. offset=500) of the result set and look 
> the first result. If it is lexicographically lower than "koala" then 
> "koala" might be in second half, on the contrary, "koala" might be in 
> the first half. Let's suppose that the first item is greater than 
> "koala", then you can jump to the middle of the first half (offset=250) 
> and apply the above dichotomy in turn until you can find if "koala" is 
> present or not. This process takes log2(N)  steps maximum.
> 
> You can't do the same through keyset pagination because you don't know 
> how the values are distributed in the result set. You can only scroll 
> the result set from the first page to the last and this process takes N 
> steps maximum.
> 
> However, in general, one is interested in all the results (or in a 
> subset) returned by a query rather than a single result. In this case, 
> provided that the results can always be sorted according to a unique 
> index, keyset pagination is more efficient than offset pagination. Let's 
> take the afore example. By offset pagination, the underlying DBMS 
> selects always 1000 results and then returns the current page so this 
> means that, in the worst case, the DBMS will select 1000 results for 10 
> times (from offset=0 to offset=900). By keyset pagination the number of 
> results the underlying DBMS selects decreases by 100 results each step. 
> At the beginning, it selects 1000 results and returns the first page, 
> then it selects 900 results and returns the second page.
> 
> Note also two facts:
> 
> - the time needed to scroll the result set could be significant when the 
> result set is huge
> 
> - for all the RDAP searchable objects, it is always possible to build 
> more or less easily a combination of properties acting as unique index 
> and this is true regardless of whether the search includes the sort 
> parameter or not. For example, for the entity object class "handle" is a 
> unique property but if the search includes "sort=registrationDate", the 
> combination <registrationDate, handle> is unique.

Thank you for the additional explanation; I don't think we need to spend
more time on this topic.

I'm looking forward to the -18!

Thanks again,

Ben

> >>> Appendix C.2
> >>>
> >>>      total count.  Therefore, as "totalCount" is an optional response
> >>>      information, fetching always the total number of rows has been
> >>>
> >>> I'm not entirely sure in what sense "optional response information" is
> >>> intended -- my reading of Section 2.1 is that it's mandatory to return
> >>> totalCount if the client included the 'count' query parameter.
> >> [ML] Exactly but it isn't returned always. For this reason, it is an
> >> optional member of the paging_metadata object.
> > Okay.  (I think your reply to another ballot comment also helped clarify
> > this for me.)
> [ML] Good.
> >> Looking forward for your reply to my questions/comments.
> > Thanks a lot for the explanations and updates; hopefully I have clarified
> > anything that was unclear.
> >
> > -Ben
> >
> > _______________________________________________
> > regext mailing list
> > regext@ietf.org
> > 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
> 