Re: [C430] AUTH48 [JM]: RFC 9002 <draft-ietf-quic-recovery-34.txt> NOW AVAILABLE

[Ian Swett <[e-mail]>]

I believe this looks correct, but I have one question as a person going
through this process for the first time.

I noticed the /rfc/ page was changed to /info/.  Is /info/, ie:
https://www.rfc-editor.org/info/rfc8985, the preferred reference URL?  I
only ask because I have never seen that style RFC page before this evening.

Thanks, Ian

On Tue, May 18, 2021 at 1:18 PM Jean Mahoney <[e-mail]> wrote:

> Martin,
>
> Thank you for the updated file. As we did in RFC 9001, we have
> explicitly set the URLs in the XML file to fix the discrepancy in
> xml2rfc output:
>
> https://www.rfc-editor.org/authors/rfc9002-xmllastrfcdiff.html (these
> changes in the XML)
> https://www.rfc-editor.org/authors/rfc9002-lastrfcdiff.html (these
> changes in the text)
>
> https://www.rfc-editor.org/authors/rfc9002.txt
> https://www.rfc-editor.org/authors/rfc9002.pdf
> https://www.rfc-editor.org/authors/rfc9002.html
> https://www.rfc-editor.org/authors/rfc9002.xml
>
> We will await further word from Jana and Ian regarding other AUTH48
> changes and/or approval.
>
> Best regards,
>
> RFC Editor/jm
>
>
> On 5/17/21 7:16 PM, Martin Thomson via C430 wrote:
> > I have these changes staged in our copy and can provide an update based
> on that.  I don't know how the rfc-editor.org links got broken though:
> the XML I have uses /info/ for all RFC reference targets.
> >
> > On Tue, May 18, 2021, at 10:02, Jana Iyengar via C430 wrote:
> >> Jean, Ian,
> >>
> >> Given that we are making these changes for the transport document, it
> >> might make sense for us to do these as well. Also so that our github
> >> repo is in line with what eventually gets published. I'm happy to make
> >> these changes.
> >>
> >> - jana
> >>
> >> On Mon, May 17, 2021 at 3:32 PM Ian Swett via C430 <[e-mail]>
> wrote:
> >>> Thanks, please make those updates.
> >>>
> >>> On Mon, May 17, 2021 at 5:25 PM Jean Mahoney <[e-mail]>
> wrote:
> >>>> Ian,
> >>>> Thank you for the updated document! We found a few small issues:
> >>>>> We found a typo ("itsestimate") in the XML that is not present in
> the markdown file in GitHub:
> >>>>>     This also
> >>     allows a connection to reset itsestimate of min_rtt and smoothed_rtt
> >>     after a disruptive network event; see Section 5.3.
> >>>>> In our edits, we had updated the [RACK] reference from
> draft-ietf-tcpm-rack-15 to the RFC that replaced it (RFC 8985). We see that
> the reference has changed back to draft-ietf-tcpm-rack-15. Is this
> intentional?
> >>>>> In the References section, the URLs for RFCs should point to the RFC
> landing page ("/info/" instead of "/rfc/"):
> >>>>>     Current:  <https://www.rfc-editor.org/rfc/rfcNNNN>
> >>>>>     Should be:  <https://www.rfc-editor.org/info/rfcNNNN>
> >>
> >>>> Would you like us to make these updates or would you like to update
> the file?
> >>>> Best regards,
> >>>> RFC Editor/jm
> >>>> On 5/7/21 12:57 PM, Ian Swett wrote:
> >>>>> Similar to Martin, I'm writing PRs to address these issues.
> >>>>>
> >>>>> Changes are in PR #4892 <
> https://github.com/quicwg/base-drafts/pull/4892> unless otherwise noted.
> I've gone over the changes with Jana and he's now approved the relevant
> PRs, so I think we're good to go.
> >>>>>
> >>>>> On Thu, Apr 29, 2021 at 2:19 PM <[e-mail]> wrote:
> >>>>>> Authors,
> >>>>>>
> >>>>>> While reviewing this document during AUTH48, please resolve
> >>>>>> (as necessary) the following questions, which are also in the XML
> file.
> >>>>>>
> >>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that
> appear in
> >>>>>> the title) for use on https://www.rfc-editor.org/search.
> >>>>>> -->
> >>>>>>
> >>>>> Thanks, in https://github.com/quicwg/base-drafts/pull/4890
> >>>>>
> >>>>>> 2) <!-- [rfced]  We have updated the cross reference to point to
> RFC 6298
> >>>>>> ("Computing TCP's Retransmission Timer") instead of RFC 6297 ("A
> Survey of
> >>>>>> Lower-than-Best-Effort Transport Protocols"). Please let us know if
> >>>>>> other changes are necessary.
> >>>>>>
> >>>>>> Original:
> >>>>>>     QUIC uses a probe timeout (PTO; see Section 6.2), with a timer
> based
> >>>>>>     on TCP's RTO computation; see [RFC6297].
> >>>>>>
> >>>>>> Current:
> >>>>>>     QUIC uses a probe timeout (PTO; see Section 6.2), with a timer
> based
> >>>>>>     on TCP's retransmission timeout (RTO) computation; see
> [RFC6298].
> >>>>>> -->
> >>>>>>
> >>>>> Thanks for catching that!
> >>>>>
> >>>>>> 3) <!-- [rfced] Does the following improve the readability of the
> paragraph?
> >>>>>>
> >>>>>> Current:
> >>>>>>     Endpoints SHOULD set the min_rtt to the newest RTT sample after
> >>>>>>     persistent congestion is established. This is to allow a
> connection
> >>>>>>     to reset its estimate of min_rtt and smoothed_rtt after a
> >>>>>>     disruptive network event (Section 5.3), and because it is
> possible
> >>>>>>     that an increase in path delay resulted in persistent congestion
> >>>>>>     being incorrectly declared.
> >>>>>>
> >>>>>> Perhaps:
> >>>>>>     Endpoints SHOULD set the min_rtt to the newest RTT sample after
> >>>>>>     persistent congestion is established because it is possible that
> >>>>>>     an increase in path delay resulted in persistent congestion
> being
> >>>>>>     incorrectly declared. This also allows a connection to reset its
> >>>>>>     estimate of min_rtt and smoothed_rtt after a disruptive network
> >>>>>>     event (Section 5.3).
> >>>>>> -->
> >>>>>>
> >>>>> I agree this is more readable, but it is subtly different, so I put
> it in a separate PR: https://github.com/quicwg/base-drafts/pull/4891
> >>>>>
> >>>>>> 4) <!-- [rfced]  In the following sentence, do implementations also
> >>>>>> increase the time threshold?
> >>>>>>
> >>>>>> Current:
> >>>>>>      Implementations can detect spurious retransmissions and
> increase
> >>>>>>      the reordering threshold in packets or time to reduce future
> >>>>>>      spurious retransmissions and loss events.
> >>>>>>
> >>>>>> Perhaps:
> >>>>>>      Implementations can detect spurious retransmissions and can
> increase
> >>>>>>      the reordering threshold in packets or increase the time
> threshold
> >>>>>>      in order to reduce future spurious retransmissions and loss
> events.
> >>>>>> -->
> >>>>>>
> >>>>> Changed to "the packet or time reordering threshold to reduce..." to
> clarify.
> >>>>>
> >>>>>> 5) <!-- [rfced] Note that we have marked this Note as an <aside>.
> >>>>>> <aside> is defined as follows:
> >>>>>>
> >>>>>>  From https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2
> >>>>>>     This element is a container for content that is semantically
> >>>>>>     less important or tangential to the content that surrounds it.
> >>>>>>
> >>>>>> Please let us know if any updates are needed.
> >>>>>> -->
> >>>>>>
> >>>>> Included in https://github.com/quicwg/base-drafts/pull/4889
> >>>>>
> >>>>>> 6) <!-- [rfced] Throughout the text, the following term appears to
> be used
> >>>>>> inconsistently. Please review these occurrences and let us know
> if/how they
> >>>>>> may be made consistent.
> >>>>>>
> >>>>>> application data / Application Data
> >>>>>>
> >>>>>> Note that RFC-to-be 9000 <draft-ietf-quic-transport> uses the
> lowercase
> >>>>>> form consistently.
> >>>>>>
> >>>>>> We raised a similar question for RFC-to-be 9001; the authors
> decided on the following:
> >>>>>>
> >>>>>>> The outcome is that figures will use title case for consistency
> (as appropriate)
> >>>>>>> and text will use the  lowercase form.  There is one reference to
> TLS
> >>>>>>> Application Data, where I have kept the title case to match the
> usage in RFC 8446.
> >>>>>> (see
> https://www.rfc-editor.org/pipermail/c430/2021-April/000016.html)
> >>>>>>
> >>>>>> -->
> >>>>> I changed the text to use "Application Data" when referring to the
> packet number space, and "application data" otherwise.
> >>>>> https://github.com/quicwg/base-drafts/pull/4893
> >>>>>
> >>>>>>
> >>>>>> 7) <!-- [rfced]  We are having difficulty parsing the following
> sentence.
> >>>>>> Could the packets be acknowledged if the keys were still available?
> >>>>>>
> >>>>>> Current:
> >>>>>>     Initial packets and Handshake packets could be never
> acknowledged,
> >>>>>>     but they are removed from bytes in flight when the Initial and
> >>>>>>     Handshake keys are discarded
> >>>>>>
> >>>>>> Perhaps:
> >>>>>>     When the Initial and Handshake keys are discarded, the Initial
> >>>>>>     packets and Handshake packets can no longer be acknowledged, and
> >>>>>>     they are removed from bytes in flight
> >>>>>> -->
> >>>>>>
> >>>>> Yes, the packets can be acknowledged until the keys are discarded,
> so I took your suggestion and added 'keys' after the first 'Initial' for
> parallelism.
> >>>>>
> >>>>>> 8) <!-- [rfced]  In the following, is "PTO timer" rather than
> "probe timer"
> >>>>>> meant?
> >>>>>>
> >>>>>> Current:
> >>>>>>     That is, the client MUST set the probe timer if the client has
> not
> >>>>>>     received an acknowledgment for any of its Handshake packets and
> the
> >>>>>>     handshake is not confirmed (see Section 4.1.2 of [QUIC-TLS]),
> even
> >>>>>>     if there are no packets in flight.
> >>>>>> -->
> >>>>>>
> >>>>>   Yes, at some point we were using "probe timer" and "PTO timer"
> interchangeably, but it's best to consistently use PTO timer. Fixed.
> >>>>>
> >>>>>> 9) <!-- [rfced] We are having difficulty parsing the following:
> >>>>>>
> >>>>>> Current:
> >>>>>>     It is expected that keys are discarded after packets encrypted
> with
> >>>>>>     them would be acknowledged or declared lost.
> >>>>>>
> >>>>>> Perhaps:
> >>>>>>     It is expected that keys are discarded at some time after the
> >>>>>>     packets encrypted with them are either acknowledged or declared
> lost.
> >>>>>>
> >>>>>> Or perhaps:
> >>>>>>     Some time after the packets are either acknowledged or declared
> lost,
> >>>>>>     the keys with which they were encrypted are discarded.
> >>>>>> -->
> >>>>>>
> >>>>>
> >>>>> The first suggestion is good, so I will use that. The second
> suggestion doesn't fully convey the intent of the sentence, IMHO.
> >>>>>
> >>>>>> 10) <!-- [rfced]  We note that RFC 9000 (draft-ietf-quic-transport)
> uses
> >>>>>> <tt> for some equations.  Please review and let us know if you
> would like
> >>>>>> the equations to appear in <tt>.
> >>>>>>
> >>>>>> Current:
> >>>>>>     Packets 2 through 8 are declared lost when the acknowledgment
> for
> >>>>>>     packet 9 is received at t = 12.2.
> >>>>>>
> >>>>>>     The congestion period is calculated as the time between the
> oldest
> >>>>>>     and newest lost packets: 8 - 1 = 7.  The persistent congestion
> >>>>>>     duration is: 2 * 3 = 6.
> >>>>>> -->
> >>>>>>
> >>>>> Good point, MT changed in
> https://github.com/quicwg/base-drafts/pull/4889
> >>>>>
> >>>>>> 11) <!-- [rfced] Does the following reordering of the sentences
> improve
> >>>>>> readability?
> >>>>>>
> >>>>>> Current:
> >>>>>>     When bytes in flight is smaller than the congestion window and
> >>>>>>     sending is not pacing limited, the congestion window is
> >>>>>>     underutilized.  When this occurs, the congestion window SHOULD
> NOT be
> >>>>>>     increased in either slow start or congestion avoidance.  This
> can
> >>>>>>     happen due to insufficient application data or flow control
> limits.
> >>>>>>
> >>>>>> Perhaps:
> >>>>>>     When the count of bytes in flight is smaller than the congestion
> >>>>>>     window and sending is not pacing limited, the congestion window
> is
> >>>>>>     underutilized, which can happen due to insufficient application
> >>>>>>     data or reduced flow control limits.  When this occurs in
> either the
> >>>>>>     slow start or congestion avoidance states, the congestion window
> >>>>>>     SHOULD NOT be increased.
> >>>>>> -->
> >>>>>>
> >>>>> I think the reordering reads more clearly, but the addition of
> "count of" does not help, so I swapped the second and third sentences.
> >>>>>
> >>>>>> 12) <!-- [rfced] We did not find the paper below published in
> January 1995.
> >>>>>> We did find one published in 1987 and a revision published in 1991.
> >>>>>> Which one should be referenced?
> >>>>>>
> >>>>>> Original:
> >>>>>>     [RETRANSMISSION]
> >>>>>>                Karn, P. and C. Partridge, "Improving Round-Trip Time
> >>>>>>                Estimates in Reliable Transport Protocols", ACM
> SIGCOMM
> >>>>>>                CCR , January 1995.
> >>>>>>
> >>>>>> Perhaps:
> >>>>>>     [RETRANSMISSION]
> >>>>>>                Karn, P. and C. Partridge, "Improving Round-Trip Time
> >>>>>>                Estimates in Reliable Transport Protocols", ACM
> SIGCOMM
> >>>>>>                Computer Communication Review, DOI
> 10.1145/55483.55484,
> >>>>>>                August 1987, <https://doi.org/10.1145/55483.55484>.
> >>>>>>
> >>>>>> Or perhaps:
> >>>>>>     [RETRANSMISSION]
> >>>>>>                Karn, P. and C. Partridge, "Improving Round-Trip Time
> >>>>>>                Estimates in Reliable Transport Protocols", ACM
> Transactions
> >>>>>>                on Computer Systems, DOI 10.1145/118544.118549,
> >>>>>>                November 1991, <
> https://doi.org/10.1145/118544.118549>.
> >>>>>> -->
> >>>>>>
> >>>>> Martin put this into https://github.com/quicwg/base-drafts/pull/4889
> >>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>> RFC Editor
> >>>>>>
> >>>>>>
> >>>>>> On Apr 29, 2021, at 11:14 AM, [e-mail] wrote:
> >>>>>>
> >>>>>> *****IMPORTANT*****
> >>>>>>
> >>>>>> Updated 2021/04/29
> >>>>>>
> >>>>>> RFC Author(s):
> >>>>>> --------------
> >>>>>>
> >>>>>> Instructions for Completing AUTH48
> >>>>>>
> >>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
> >>>>>> approved by you and all coauthors, it will be published as an RFC.
> >>>>>> If an author is no longer available, there are several remedies
> >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>>>
> >>>>>> You and you coauthors are responsible for engaging other parties
> >>>>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>>>> your approval.
> >>>>>>
> >>>>>> Planning your review
> >>>>>> ---------------------
> >>>>>>
> >>>>>> Please review the following aspects of your document:
> >>>>>>
> >>>>>> *  RFC Editor questions
> >>>>>>
> >>>>>>    Please review and resolve any questions raised by the RFC Editor
> >>>>>>    that have been included in the XML file as comments marked as
> >>>>>>    follows:
> >>>>>>
> >>>>>>    <!-- [rfced] ... -->
> >>>>>>
> >>>>>>    These questions will also be sent in a subsequent email.
> >>>>>>
> >>>>>> *  Changes submitted by coauthors
> >>>>>>
> >>>>>>    Please ensure that you review any changes submitted by your
> >>>>>>    coauthors.  We assume that if you do not speak up that you
> >>>>>>    agree to changes submitted by your coauthors.
> >>>>>>
> >>>>>> *  Content
> >>>>>>
> >>>>>>    Please review the full content of the document, as this cannot
> >>>>>>    change once the RFC is published. Please pay particular
> attention to:
> >>>>>>    - IANA considerations updates (if applicable)
> >>>>>>    - contact information
> >>>>>>    - references
> >>>>>>
> >>>>>> *  Copyright notices and legends
> >>>>>>
> >>>>>>    Please review the copyright notice and legends as defined in
> >>>>>>    RFC 5378 and the Trust Legal Provisions
> >>>>>>    (TLP – https://trustee.ietf.org/license-info/).
> >>>>>>
> >>>>>> *  Semantic markup
> >>>>>>
> >>>>>>    Please review the markup in the XML file to ensure that elements
> of
> >>>>>>    content are correctly tagged.  For example, ensure that
> <sourcecode>
> >>>>>>    and <artwork> are set correctly.  See details at
> >>>>>>    <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
> >>>>>>
> >>>>>> *  Formatted output
> >>>>>>
> >>>>>>    Please review the PDF, HTML, and TXT files to ensure that the
> >>>>>>    formatted output, as generated from the markup in the XML file,
> is
> >>>>>>    reasonable.  Please note that the TXT will have formatting
> >>>>>>    limitations compared to the PDF and HTML.
> >>>>>>
> >>>>>>
> >>>>>> Submitting changes
> >>>>>> ------------------
> >>>>>>
> >>>>>> To submit changes, please reply to this email with one of the
> following,
> >>>>>> using ‘REPLY ALL’ as all the parties CC’ed on this message need to
> see
> >>>>>> your changes:
> >>>>>>
> >>>>>> An update to the provided XML file
> >>>>>> — OR —
> >>>>>> An explicit list of changes in this format
> >>>>>>
> >>>>>> Section # (or indicate Global)
> >>>>>>
> >>>>>> OLD:
> >>>>>> old text
> >>>>>>
> >>>>>> NEW:
> >>>>>> new text
> >>>>>>
> >>>>>> You do not need to reply with both an updated XML file and an
> explicit
> >>>>>> list of changes, as either form is sufficient.
> >>>>>>
> >>>>>> We will ask a stream manager to review and approve any changes that
> seem
> >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> >>>>>> and technical changes.  Information about stream managers can be
> found in
> >>>>>> the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >>>>>>
> >>>>>>
> >>>>>> Approving for publication
> >>>>>> --------------------------
> >>>>>>
> >>>>>> To approve your RFC for publication, please reply to this email s
> >>>>>> tating that you approve this RFC for publication.  Please use
> ‘REPLY ALL’
> >>>>>> as all the parties CC’ed on this message need to see your approval.
> >>>>>>
> >>>>>>
> >>>>>> Files
> >>>>>> -----
> >>>>>>
> >>>>>> The files are available here:
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002.xml
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002.html
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002.pdf
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002.txt
> >>>>>>
> >>>>>> Diff file of the text:
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002-diff.html
> >>>>>>
> >>>>>> Diff of the XML:
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002-xmldiff1.html
> >>>>>>
> >>>>>> The following file is provided to facilitate creation of your own
> >>>>>> diff files of the XML.  This file is a best effort to capture
> v3-related format updates only:
> >>>>>>    https://www.rfc-editor.org/authors/rfc9002.form.xml
> >>>>>>
> >>>>>>
> >>>>>> Tracking progress
> >>>>>> -----------------
> >>>>>>
> >>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>    https://www.rfc-editor.org/auth48/rfc9002
> >>>>>>
> >>>>>> Please let us know if you have any questions.
> >>>>>>
> >>>>>> Thank you for your cooperation,
> >>>>>>
> >>>>>> RFC Editor
> >>>>>>
> >>>>>> --------------------------------------
> >>>>>> RFC9002 (draft-ietf-quic-recovery-34)
> >>>>>>
> >>>>>> Title            : QUIC Loss Detection and Congestion Control
> >>>>>> Author(s)        : J. Iyengar, Ed., I. Swett, Ed.
> >>>>>> WG Chair(s)      : Lars Eggert, Lucas Pardue, Matt Joras
> >>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> >>>>>>
> >>>>>>
> >>>>>>
> >>> --
> >>> C430 mailing list
> >>> [e-mail]
> >>> https://www.rfc-editor.org/mailman/listinfo/c430
> >> --
> >> C430 mailing list
> >> [e-mail] <mailto:C430%40rfc-editor.org>
> >> https://www.rfc-editor.org/mailman/listinfo/c430
> >>
>