Re: Robert Wilton's No Objection on draft-ietf-quic-qpack-20: (with COMMENT)

[Lucas Pardue <[e-mail]>]

Hi Robert,

Thanks for the review. I've created GitHub issue(s) to track each comment
on the QUIC WG repository, see the URL(s) in line.

On Thu, Jan 21, 2021 at 9:38 AM Robert Wilton via Datatracker <
[e-mail]> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-quic-qpack-20: 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-quic-qpack/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for this well written document, like Eric I found it interesting
> to
> read.
>
> A few non blocking comments:
>
> I didn't read the draft in complete detail, but I'm not sure that I came
> away
> with a good understanding of what the receiver data structure would
> actually
> look like in an implementation.  The first paragraph in section 3.2
> suggests
> that this would be a list of field lines in FIFO order, but I would assume
> that
> a more performant representation would likely be used.  I appreciate that
> this
> is really an implementation detail, but possibly the introduction in
> section
> 3.2 might benefit with text giving a bit more overview of what the data
> structure is expected to look like.
>

https://github.com/quicwg/base-drafts/issues/4800


> A couple of places in the document have pseudo code, which I presume is
> written
> in Python.  Possibly, it might be helpful to readers to indicate that the
> pseudo code follows a Python style syntax, although it is pretty intuitive
> regardless.
>

https://github.com/quicwg/base-drafts/issues/4801


> Section 7.4 talks about implementation limits, but it wasn't obvious to me
> how
> a receiver is expected to behave if one of those limits is exceeded.
> Further
> in the case of strings, there seems to be a simple upper bound on the
> maximum
> size of the string of the table size.
>

https://github.com/quicwg/base-drafts/issues/4802


> I note that the algorithm uses a static table.  Is there any consideration
> to
> be able to update or evolve that static table over time?  E.g., perhaps in
> 10
> years time, the traffic will have changed sufficiently enough that a new
> version of the static table should be generated.
>

https://github.com/quicwg/base-drafts/issues/4803

Cheers
Lucas
On behalf of QUIC WG Chairs