Re: Éric Vyncke's No Objection on draft-ietf-quic-applicability-16: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Sorry for such a belated reply :(...

Look below for EV>

On 13/05/2022, 06:58, "Mirja Kuehlewind" <[e-mail]> wrote:

    Hi Eric,

    thanks for your review and your kind words!

    I'm opening github issue for most reviews right now but for your comments it's not fully clear to me how to address them, so I'm replying by email first. Please see below!

    Mirja


    On 19.04.22, 13:20, "Éric Vyncke via Datatracker" <[e-mail]> wrote:

        Éric Vyncke has entered the following ballot position for
        draft-ietf-quic-applicability-16: No Objection

        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:
        ----------------------------------------------------------------------

        Thank you for the work put into this document. Such a document is important for
        developers / operators wanting to use the new transport.

        Please find below some non-blocking COMMENT points (but replies would be
        appreciated even if only for my own education).

        Special thanks to Matt Joras for the shepherd's write-up including the WG
        consensus and the intended status.

        I hope that this helps to improve the document,

        Regards,

        -éric

        Should there be a section about temporary address extension for IPv6 addresses
        RFC 8981 (as some OS can be very aggressive in changing to the next IPv6
        address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one
        sentence in the introduction could be useful.

        What is the recommendation for these addresses, should the application keep
        always the first address as long as it is valid ? or should it switch to a new
        one ?

    [MK] I don't think this a problem as the address is usually (at least today) not changed during an on-going connection, or? 

EV> the previously used address may have become invalid (i.e., has expired) but this would only happen on very long-lasting connections. But my question is still the same: should the QUIC application tries to keep the 'original' address or should it try to use the most recent one? Giving guidance would be desirable?


        ## Section 2

        "permits traversal of network middleboxes (including NAT)" could perhaps be
        refined as TCP also traverse NAT, perhaps something such as "using a new IP
        protocol would have issue with network middleboxes (Internet ossification)" ?

    [MK] I guess this should be rather s/IP protocol/transport protocol/. However, developing a new transport protocol on top of TCP doesn't make to much sense. I find the sense actually clear and straight-forward. Tending to not change anything...

EV> as you prefer

        ## Section 4.4 (and some others)

        Sometimes the text is a little unclear on which part of the "application using
        QUIC" is discussed: the transport layer or the application layer in the
        "application" ? Unsure whether it is only me having this confusion though and I
        have no real suggestion on how to clarify things.

    [MK] Sorry this comment is not clear to me. Can you further explain?

EV> my confusion may be sourced in my lack of QUIC understanding but I fail to understand which the explanations/recommendations are related to which part (either QUIC itself or in the application actually using QUIC). If this is clear for everyone, then I am in the rough and leave the text as it is.

        ## Section 5

        For the last paragraph, should a reference to a TAPS API/parameter be given ?
        (if it exists of course)

    [MK] I don't think so; taps doesn't consider this specifically.

EV> fair enough then ignore