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

[Jean Mahoney <[e-mail]>]

Ian,

We have noted your approval on the AUTH48 status page:

    https://www.rfc-editor.org/auth48/rfc9002

As approvals are now complete, we will move this document forward in the 
publication process (along with the other documents in its cluster when 
they have completed AUTH48):

    https://www.rfc-editor.org/auth48/C430

Thank you!

RFC Editor/jm

On 5/20/21 8:21 AM, Ian Swett wrote:
> I approve the revised document as well.
>
> On Wed, May 19, 2021 at 4:11 PM Jean Mahoney <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Jana,
>
>     We have noted your approval on the AUTH48 status page:
>
>     https://www.rfc-editor.org/auth48/rfc9002
>     <https://www.rfc-editor.org/auth48/rfc9002>
>
>     We will await further word from Ian regarding other AUTH48 changes
>     and/or approval.
>
>     Thank you!
>
>     RFC Editor/jm
>
>     On 5/19/21 1:19 PM, Jana Iyengar wrote:
>>     Hi Jean,
>>
>>     Thank you for the revised document - I've gone through it and it
>>     looks good. Thank you for your work!
>>
>>     - jana
>>
>>     On Wed, May 19, 2021 at 7:04 AM Ian Swett <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Thanks for the extra information, that makes sense.
>>
>>         On Wed, May 19, 2021 at 10:03 AM Jean Mahoney
>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>             Hi Ian,
>>
>>             On 5/18/21 10:32 PM, Ian Swett wrote:
>>>             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/
>>>             <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.
>>
>>             Yes. While both URLs work, the URL constructed with
>>             /info/ places the reader on the information page, which
>>             allows the reader to select the file format (pdf, html,
>>             txt, html with errata) and also highlights the metadata
>>             (updates, obsoletes, DOI, working group, stream
>>             information, etc.). The information page is also
>>             extensible, allowing new details about the document to be
>>             added in the future, whereas the /rfc/ page would be
>>             limited to the document itself.
>>
>>             Thanks for asking! Please let me know if you have any
>>             more questions.
>>
>>             Jean
>>
>>
>>>
>>>             Thanks, Ian
>>>
>>>             On Tue, May 18, 2021 at 1:18 PM Jean Mahoney
>>>             <[e-mail] <mailto:[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
>>>                 <https://www.rfc-editor.org/authors/rfc9002-xmllastrfcdiff.html>
>>>                 (these
>>>                 changes in the XML)
>>>                 https://www.rfc-editor.org/authors/rfc9002-lastrfcdiff.html
>>>                 <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.txt>
>>>                 https://www.rfc-editor.org/authors/rfc9002.pdf
>>>                 <https://www.rfc-editor.org/authors/rfc9002.pdf>
>>>                 https://www.rfc-editor.org/authors/rfc9002.html
>>>                 <https://www.rfc-editor.org/authors/rfc9002.html>
>>>                 https://www.rfc-editor.org/authors/rfc9002.xml
>>>                 <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 <http://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]
>>>                 <mailto:[e-mail]>> wrote:
>>>                 >>> Thanks, please make those updates.
>>>                 >>>
>>>                 >>> On Mon, May 17, 2021 at 5:25 PM Jean Mahoney
>>>                 <[e-mail] <mailto:[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
>>>                 <https://www.rfc-editor.org/rfc/rfcNNNN>>
>>>                 >>>>>     Should be: 
>>>                 <https://www.rfc-editor.org/info/rfcNNNN
>>>                 <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
>>>                 <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]
>>>                 <mailto:[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
>>>                 <https://www.rfc-editor.org/search>.
>>>                 >>>>>> -->
>>>                 >>>>>>
>>>                 >>>>> Thanks, in
>>>                 https://github.com/quicwg/base-drafts/pull/4890
>>>                 <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
>>>                 <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
>>>                 <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
>>>                 <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
>>>                 <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
>>>                 <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
>>>                 <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
>>>                 <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
>>>                 <https://doi.org/10.1145/118544.118549>>.
>>>                 >>>>>> -->
>>>                 >>>>>>
>>>                 >>>>> Martin put this into
>>>                 https://github.com/quicwg/base-drafts/pull/4889
>>>                 <https://github.com/quicwg/base-drafts/pull/4889>
>>>                 >>>>>
>>>                 >>>>>> Thank you.
>>>                 >>>>>>
>>>                 >>>>>> RFC Editor
>>>                 >>>>>>
>>>                 >>>>>>
>>>                 >>>>>> On Apr 29, 2021, at 11:14 AM,
>>>                 [e-mail]
>>>                 <mailto:[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/
>>>                 <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/
>>>                 <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
>>>                 <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.xml>
>>>                 >>>>>>
>>>                 https://www.rfc-editor.org/authors/rfc9002.html
>>>                 <https://www.rfc-editor.org/authors/rfc9002.html>
>>>                 >>>>>>
>>>                 https://www.rfc-editor.org/authors/rfc9002.pdf
>>>                 <https://www.rfc-editor.org/authors/rfc9002.pdf>
>>>                 >>>>>>
>>>                 https://www.rfc-editor.org/authors/rfc9002.txt
>>>                 <https://www.rfc-editor.org/authors/rfc9002.txt>
>>>                 >>>>>>
>>>                 >>>>>> Diff file of the text:
>>>                 >>>>>>
>>>                 https://www.rfc-editor.org/authors/rfc9002-diff.html
>>>                 <https://www.rfc-editor.org/authors/rfc9002-diff.html>
>>>                 >>>>>>
>>>                 >>>>>> Diff of the XML:
>>>                 >>>>>>
>>>                 https://www.rfc-editor.org/authors/rfc9002-xmldiff1.html
>>>                 <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
>>>                 <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
>>>                 <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] <mailto:[e-mail]>
>>>                 >>> https://www.rfc-editor.org/mailman/listinfo/c430
>>>                 <https://www.rfc-editor.org/mailman/listinfo/c430>
>>>                 >> --
>>>                 >> C430 mailing list
>>>                 >> [e-mail] <mailto:[e-mail]>
>>>                 <mailto:C430%40rfc-editor.org
>>>                 <mailto:C430%2540rfc-editor.org>>
>>>                 >> https://www.rfc-editor.org/mailman/listinfo/c430
>>>                 <https://www.rfc-editor.org/mailman/listinfo/c430>
>>>                 >>
>>>