#89: get-entries: "end" greater than "tree_size" should be allowed
There could be skew between frontends of a log server that uses a distributed implementation, which means that a get-sth request could return a certain tree size, but that a follow up get-entries request could go to another frontend that is slightly behind, and not have all the entries necessary. At the minimum, this bit of section 4.7 should be removed: > The "start" and "end" parameters SHOULD be within the range 0 <= x < "tree_size" as returned by "get-sth" in Section 4.3. That paragraph already somewhat conflicts with this later paragraph in the same section: > Because of skew, it is possible the log server will not have any entries between "start" and "end". In this case it MUST return an empty "entries" array. This should be clarified that a log server might not have *all* the entries (it might still have some of them). If a subset is returned, I feel that the entries should still be sequential and begin with the entry specified by "start", of course. Looking at some of the new methods designed to work reduce the impact of possible skew (like "get-all-by-hash"), one could imagine a new method that returns both entries and the latest STH, so that whatever is obtained can be verified. For example, if "get-sth" gave a tree size of 10, and the client then issues a "get-entries" with a "start" of 5, and an "end" of 9, but the frontend this request goes to only has a tree size of 8, it could return entries 5 to 7, as well as an STH with a tree size of 8, so that those entries could be verified. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/89> trans <http://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
