Re: [Last-Call] Dnsdir last call review of draft-ietf-quic-version-negotiation-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

thank you.

Could you add one more forward reference to the Special Handling section. I would expect it somewhere after

> 2.  Version Negotiation Mechanism
> The client's first flight includes Version Information ...

HTH.
Petr Špaček


On 11. 10. 22 20:11, David Schinazi wrote:
Hi Petr, thank you for your review.
I prefer to keep the current ordering of the document, but I've added a reference to the definition of transport parameters as you suggested:
https://github.com/quicwg/version-negotiation/commit/b07f813b0f4bedf874d2b6f50175d6a5de183560 <https://github.com/quicwg/version-negotiation/commit/b07f813b0f4bedf874d2b6f50175d6a5de183560>
David

On Tue, Oct 11, 2022 at 1:54 AM Petr Špaček via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:

    Reviewer: Petr Špaček
    Review result: Ready with Nits

    The document contains no direct or indirect reference to the DNS.

    I'm unfamiliar with QUIC protocol details and thus not qualified to make
    detailed comments on the protocol. On the surface, it looks good.

    The document is clearly motivated, and the proposed mechanism's
    description
    contains helpful examples throughout the whole document.

    A list of nits follows, very likely as a matter of personal taste -
    feel free
    to ignore:

     >From my perspective, the document overuses forward references to
    itself, which
    makes it harder to follow.

    a) Section 8 Special Handling for QUIC Version 1
    It would be nice if this section were mentioned in the beginning.
    For a while,
    I thought the proposed protocol could not work because I did not
    notice special
    handling in the Table of contents. I would put it forwarding,
    possibly as a
    subsection of the Version Information section.

    b) The first mention of "transport parameter" could use a reference
    to RFC 9000
    sec. 7.4 to make it easier for the reader.

    c) Also, section 5.  Server Deployments of QUIC forward could appear
    earlier,
    possibly as a subsection of the Version Information section.

    For me personally more logical text flow would be:

        1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .
    .   3
        3.  Version Information . . . . . . . . . . . . . . . . . . . .
    .   8
           8.  Special Handling for QUIC Version 1 . . . . . . . . . . .
    . .  15
           5.  Server Deployments of QUIC  . . . . . . . . . . . . . . .
    . .  11
        2.  Version Negotiation Mechanism . . . . . . . . . . . . . . .
    .   4
        4.  Version Downgrade Prevention  . . . . . . . . . . . . . . .
    .  10

    With enough jumping back and forth, the document makes sense, so
    again, feel
    free to ignore me.

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux