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

[Barry Leiba via Datatracker <[e-mail]>]

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.

— 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.

— 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?

— 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....”

— 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.”