Robert Wilton has entered the following ballot position for draft-ietf-quic-applicability-16: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. I think that these sorts of documents are incredibly helpful and important for end users who are considering how to use IETF technology. I found the document to be well written, and only had a few minor comments/questions: 1. If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by the receiver. Therefore, an application can use the maximum number of allowed, currently open, and currently used streams when determining how to map data to streams. I was wondering whether "can use" is right here, or whether this should be "must use", given that the client cannot necessarily control how many streams are available. 7. Acknowledgment Efficiency QUIC version 1 without extensions uses an acknowledgment strategy adopted from TCP Section 13.2 of [QUIC]). Nit: This doesn't quite scan/read easily. 9. Connection Migration QUIC supports connection migration by the client. If an IP address changes, a QUIC endpoint can still associate packets with an existing For clarity, perhaps: If an IP address changes => If the client IP address changes? Thanks, Rob
