Re: Robert Wilton's Yes on draft-ietf-quic-applicability-16: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Rob,

thanks for your review and nice words! We created a PR for your minor edits!

Mirja



On 20.04.22, 18:58, "Robert Wilton via Datatracker" <[e-mail]> wrote:

    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