Hi Barry, Thanks for the review. I've captured your comments as issues on the QUIC WG GItHub repository. Links to each are provided as in-line responses.
On Wed, Jan 6, 2021 at 12:02 AM Barry Leiba via Datatracker < [email protected]> wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-quic-transport-33: Yes > > 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-transport/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the great work on this important protocol, and for a very well > written document! Just some very minor editorial comments: > > — Section 3.5 — > An endpoint SHOULD copy the error code from the STOP_SENDING frame to > the RESET_STREAM frame it sends, but MAY use any application error > code. > https://github.com/quicwg/base-drafts/issues/4558 > — Section 9.6.2 — > It SHOULD drop packets > for this connection received on the old IP address, but MAY continue > to process delayed packets. > > Do as you think best with cases such as these, but for my part, I dislike > the > “SHOULD... but MAY” formulation, as I find it contradictory when it’s read > strictly. In general, I prefer to simply avoid the BCP 14 key word for the > second part (“SHOULD do x, but may make other choices”). In both cases > here, > I’d probably just leave off the second part, as it doesn’t seem to add > anything. At the least, I encourage making it “may” (or “can”). But > again, as > you think best. > https://github.com/quicwg/base-drafts/issues/4559 > — Section 4 — > > It is necessary to limit the amount of data that a receiver could > buffer, to prevent a fast sender from overwhelming a slow receiver, > or to prevent a malicious sender from consuming a large amount of > memory at a receiver. > > You’re not talking about limiting the ability of the receiver (“could > buffer”), > but limiting the potential buffering requirement on the client (“has to > buffer”), yes? > https://github.com/quicwg/base-drafts/issues/4560 > — Section 4.1 — > > Once a receiver advertises a limit for the connection or a stream, it > MAY advertise a smaller limit, but this has no effect. > > I don’t think this really fits the spirit of “MAY”. I would say, “it is > not an > error to advertise a smaller limit, but....” > https://github.com/quicwg/base-drafts/issues/4562 > — Section 7 — > > Once completed, endpoints are able to exchange > application data. > > The antecedent to “once completed” is dangling, and the previous sentence > talks > about exchanging application data earlier. I suggest, “Once the handshake > is > completed, endpoints are able to exchange application data freely.” > > https://github.com/quicwg/base-drafts/issues/4563 Cheers, Lucas On behalf of QUIC WG Chairs
