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 < [email protected]> 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
