Opened 7 years ago

Closed 6 years ago

#95 closed defect (wontfix)

Should the response size to get-entries be a part of the log metadata?

Reported by: eranm@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:


Section 4.7 says logs MAY restrict the number of entries that can be retrieved.
It should be a part of the log's metadata so clients can know it ahead of time.

Change History (7)

comment:1 Changed 7 years ago by eranm@…

  • Component changed from client-behavior to rfc6962-bis

Note that this does limit the log's ability to dynamically choose the limit.

comment:2 Changed 7 years ago by benl@…

Disagree. Whilst I can see there might be some slight advantage to the client, what would we do if the server broke the promise, and why?

Also, response size limit may be based on dynamic considerations (load, caching, size of responses, etc).

comment:3 Changed 7 years ago by eranm@…

  • Summary changed from The response size to get-entries should be a part of the log metadata to Should the response size to get-entries be a part of the log metadata?

Original suggestion was by Steve Kent.
I agree with some of Ben's comments - as a compromise we can suggest a default of X entries that would generate Y amount of traffic per request (as an implementation guideline), allowing logs to deviate depending on their loads or implementations.

comment:4 Changed 6 years ago by eranm@…

To clarify - get-entries is not used by the client when fetching an inclusion proof, but by monitors for bulk fetching of entries.
As such, the RFC could recommend a number with logs being free to dynamically vary it.

comment:6 Changed 6 years ago by eranm@…

  • Milestone set to review

There's a consensus among the authors that adding text suggesting a response size for get-entries is not very useful ultimately and so is not essential to the document.
Rob explains:
"For's, I currently fetch (up to) 1,024 entries per get-entries request. I arrived at this strategy by trial and error. It would be nice to have more determinism here, but simply suggesting a limit in the doc wouldn't actually help with that, because I'd still have to figure out what the logs are actually doing by trial and error. So I agree with Ben: let's close ticket 95 as a WONTFIX."

From an implementation perspective a suggestion will not help.

comment:7 Changed 6 years ago by paul@…

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.