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

[Robert Wilton via Datatracker <[e-mail]>]

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.

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.

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.

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.