Re: Barry Leiba's Yes on draft-ietf-quic-transport-33: (with COMMENT)

[Lucas Pardue <[e-mail]>]

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 <
[e-mail]> 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