Subject: [Trans] [trans] #95 (client-behavior): The response size to get-entries should be a part of the log metadata

From: "trans issue tracker" <[email-masked]>
Date: Thu, 23 Jul 2015 08:43:24 -0000

#95: The response size to get-entries should be a part of the log metadata

 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.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]       |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  client-      |    Version:
  behavior               |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/95>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 23 Jul 2015 08:45:37 -0000

Changes (by [email-masked]):

 * component:  client-behavior => rfc6962-bis

Comment:

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

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]       |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:1>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 23 Jul 2015 09:19:50 -0000

Comment (by [email-masked]):

 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).

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 23 Jul 2015 09:48:22 -0000

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

Comment (by [email-masked]):

 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.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jul 2015 17:27:55 +0200

I am now convinced that the response size may have to vary dynamically.
I suggest the log spec (aka 6962-bis) should mandate a minimum size for
the get-entries query for all logs (to address privacy concerns).

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 24 Jul 2015 15:40:13 +0000

> the get-entries query for all logs (to address privacy concerns).

As I noted in response to the agenda writeup, I am not convinced by this -
the easy way to mitigate the privacy concern is for the client to preselect
the entries it wishes to fetch, and fetch all of them regardless of reduced
responses (through multiple requests, obviously).

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

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 27 Jul 2015 16:33:29 -0000

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.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:4>
trans <http://tools.ietf.org/trans/>