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

[Mirja Kuehlewind <[e-mail]>]

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? 

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

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

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