Re: [auth48] AUTH48: RFC-to-be 9312 <draft-ietf-quic-manageability-18> for your review

[Jean Mahoney <[e-mail]>]

Thank you, Mirja! We have noted your approval on the AUTH48 status page:

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

We have updated the reference to [QUIC-APPLICABILITY] to point to RFC 9308:

   https://www.rfc-editor.org/authors/rfc9312-lastrfcdiff.html

This document will now move forward in the publication process.

Best regards,
RFC Editor/jm


On 9/22/22 8:34 AM, Mirja Kuehlewind wrote:
> Hi Jean,
>
> thanks for the updates! I approve this as well.
>
> Mirja
>
>
> On 21.09.22, 22:59, "Jean Mahoney" <[e-mail]> wrote:
>
>      Brian,
>
>      Thank you for your response and your approval on this document as well.
>      Your approval has been noted on the AUTH48 status page:
>
>          https://www.rfc-editor.org/auth48/rfc9312
>
>      And we have updated the document with your feedback:
>
>          https://www.rfc-editor.org/authors/rfc9312-lastrfcdiff.html (these
>      changes side by side)
>
>          https://www.rfc-editor.org/authors/rfc9312.txt
>          https://www.rfc-editor.org/authors/rfc9312.pdf
>          https://www.rfc-editor.org/authors/rfc9312.html
>          https://www.rfc-editor.org/authors/rfc9312.xml
>          https://www.rfc-editor.org/authors/rfc9312-diff.html (all changes
>      inline)
>          https://www.rfc-editor.org/authors/rfc9312-rfcdiff.html (all changes
>      side by side)
>          https://www.rfc-editor.org/authors/rfc9312-auth48diff.html (all
>      AUTH48 changes)
>          https://www.rfc-editor.org/authors/rfc9312-alt-diff.html
>          https://www.rfc-editor.org/authors/rfc9312-xmldiff1.html (all XML
>      changes inline)
>          https://www.rfc-editor.org/authors/rfc9312-xmldiff2.html (all XML
>      changes side by side)
>
>      We'll await word from Mirja regarding other AUTH48 updates and/or approval.
>
>      Best regards,
>      RFC Editor/jm
>
>      On 9/21/22 8:34 AM, Brian Trammell (IETF) wrote:
>      > Greetings,
>      >
>      > Replies inline.
>      >
>      >> On 12 Sep 2022, at 23:58, [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 provide any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search.
>      >> -->
>      > network management, wire image
>      >
>      >> 2) <!-- [rfced] Section 1: We suggest rewording this sentence to avoid awkward phrasing. In particular, "than is the case" seems out of place. Does the suggested text change the original meaning of the sentence?
>      >>
>      >> Original:
>      >>    Encryption of most transport-layer control
>      >>    signaling means that less information is visible to the network than
>      >>    is the case with TCP.
>      >>
>      >> Perhaps:
>      >>    Encryption of most transport-layer control
>      >>    signaling means that less information is visible to the network in
>      >>    comparison to TCP.
>      >> -->
>      > This edit is fine.
>      >
>      >> 3) <!-- [rfced] Section 2.1: We do not see "version number field" in Section 17.2.1 of RFC 9000. Is "Version field" meant?
>      >>
>      >> Current:
>      >>       During Version
>      >>       Negotiation (see Section 17.2.1 of [QUIC-TRANSPORT] and
>      >>       Section 2.8), the version number field has a special value
>      >>       (0x00000000)...
>      >>
>      >> If so, should "version number field" be "Version field" in Section 2.8?:
>      >>
>      >> Current:
>      >>    Use of the version number field for
>      >>    traffic recognition will therefore behave differently than with these
>      >>    protocols.  Using a particular version number to recognize valid QUIC
>      >>    traffic is likely to persistently miss a fraction of QUIC flows and
>      >>    completely fail in the near future.  Reliance on the version number
>      >>    field for the purposes of admission control...
>      >> -->
>      > Yes, please change to “Version field” in both instances.
>      >
>      >> 4) <!-- [rfced] Section 2.1: The last sentence of this paragraph seems somewhat redundant with the first sentence given here. Or is the phrase "other versions" implying "unregistered versions"? Please let us know how we may update the last sentence.
>      >>
>      >> Current:
>      >>       ... Operators should
>      >>       expect to observe packets with other version numbers as a result
>      >>       of various Internet experiments, future standards, and greasing
>      >>       [RFC7801].  An IANA registry contains the values of all
>      >>       standardized versions of QUIC, and may contain some proprietary
>      >>       versions (see Section 22.2 of [QUIC-TRANSPORT]).  However, other
>      >>       versions of QUIC can be expected to be seen in the Internet at any
>      >>       given time.
>      >> -->
>      > The working group spent quite a lot of time on this wording. The redundancy is intentional, and any edit to it would require discussion within the WG. We’d prefer not to touch it.
>      >
>      >> 5) <!-- [rfced] Section 2.1: Would clarifying actors and actions make the following clearer?
>      >>
>      >> Current:
>      >>       The Source Connection ID corresponds to the Destination Connection
>      >>       ID the source would like to have on packets sent to it, and is
>      >>       only present on long headers.  On long header packets, the length
>      >>       of the connection IDs is also present; on short header packets,
>      >>       the length of the Destination Connection ID is implicit and need
>      >>       to be known as such from the long header packets.
>      >>
>      >> Perhaps (Making the first sentence more active ("The source adds", "the source indicates", "the destination uses"), and changing "need to be known as such" to "thus needs to be known" in the second sentence):
>      >>       The source adds a Source Connection ID to long headers only. By
>      >>       specifying a Source Connection ID, the source indicates what
>      >>       the destination uses when constructing a Destination Connection
>      >>       ID, which specifies where the source would like to have packets
>      >>       sent.  On long header packets, the length
>      >>       of the connection IDs is also present; on short header packets,
>      >>       the length of the Destination Connection ID is implicit and thus
>      >>       needs to be known from the long header packets.
>      >> -->
>      > After a bit of discussion we've settled on
>      >
>      > NEW:
>      >
>      > The Source Connection ID is
>      > only present on long headers and indicates the Destination Connection
>      > ID that the other endpoint should use when sending packets.
>      > On long header packets, the length
>      > of the connection IDs is also present; on short header packets,
>      > the length of the Destination Connection ID is implicit, as it is known
>      > from preceding long header packets.
>      >
>      >> 6) <!--[rfced] Section 2.1: "Of" is present in this sentence three times, which may affect comprehension for some readers. How may we update this sentence for easy comprehension while maintaining technical accuracy?
>      >>
>      >> Original:
>      >>       The second-most-significant bit of the first octet of
>      >>       most QUIC packets of the current version is set to 1, enabling
>      >>       endpoints to demultiplex with other UDP-encapsulated protocols.
>      >>
>      >> Perhaps:
>      >>       In version 1 of QUIC, most QUIC packets have the
>      >>       second-most-significant bit of the first octet set to 1, enabling
>      >>       endpoints to demultiplex with other UDP-encapsulated protocols.
>      >> -->
>      > Let’s be a bit more concrete.
>      >
>      > NEW:
>      >
>      > In version 1 of QUIC, the second-most-significant bit of the first octet is set to 1,
>      > unless the packet is a Version Negotiation packet or
>      > an extension is used that modifies the usage of this bit. If the bit is set to 1, it enables
>      > endpoints to easily demultiplex with other UDP-encapsulated protocols.
>      >
>      >> 7) <!-- [rfced] Section 2.1: Please help us clarify "forgibly" in the sentence below. Does it mean that packets are protected against forgery?
>      >>
>      >> Original:
>      >>       Retry packets are (forgibly) integrity protected.
>      >> -->
>      > This text is outdated as well as being unclear; please cut the parenthetical:
>      >
>      > NEW:
>      >
>      > Retry packets are integrity protected.
>      >
>      >> 8) <!-- [rfced] Section 2.2: We have updated the following to improve readability. Please let us know if any changes are necessary.
>      >>
>      >> Original:
>      >>    The Length field is variable
>      >>    length, and its position in the header is also variable depending on
>      >>    the length of the source and destination connection ID;
>      >>
>      >> Current (updating "is also variable" to "also varies" and making "length" and "ID" plural):
>      >>    The Length field is a
>      >>    variable-length field, and its position in the header also varies
>      >>    depending on the lengths of the Source and Destination Connection
>      >>    IDs;
>      >> -->
>      > This edit is good.
>      >
>      >> 9) <!-- [rfced] Section 2.4: We suggest rephrasing this sentence in order to clarify the exact minimum packet size. Does the suggested text change the meaning of the original sentence?
>      >>
>      >> Original:
>      >>    A network path needs to be able to forward at least this size of
>      >>    packet for QUIC to be used.
>      >>
>      >> Perhaps:
>      >>    A network path needs to be able to forward at least the size of
>      >>    an Initial packet in order for QUIC to be used.
>      >> —>
>      > The suggestion does alter the meaning of the sentence; we’re referring back to 1200 bytes of UDP payload. However, the word order is a bit clunky. How about NEW:
>      >
>      > A network path needs to be able to forward packets of at least this size for QUIC to be used.
>      >
>      >> 10) <!-- [rfced] Section 2.8: We suggest rephrasing this sentence for easy comprehension or limiting the number of adverbs in this sentence. Overuse of adverbs in this context may confuse readers.
>      >>
>      >> Original:
>      >>    Reliance on the version number
>      >>    field for the purposes of admission control is similarly likely to
>      >>    rapidly lead to unintended failure modes.
>      >>
>      >> Perhaps:
>      >>    Similarly, reliance on the version number
>      >>    field for the purpose of admission control is likely to rapidly lead
>      >>    to unintended failure modes.
>      >> -->
>      > A bit more rewording to make the flow better; NEW:
>      >
>      > Reliance on the version number field for the purpose of
>      > admission control is also likely to lead to unintended failure modes.
>      >
>      >
>      >> 11) <!-- [rfced]  Section 3.8.2: We suggest rephrasing this sentence to avoid awkward phrasing/comma usage. Does the suggested text change the original intended meaning?
>      >>
>      >> Original:
>      >>    When the sender is application-
>      >>    limited and e.g., only sends small amount of periodic application
>      >>    traffic, where that period is longer than the RTT, measuring the spin
>      >>    bit provides information about the application period, not the
>      >>    network RTT.
>      >>
>      >> Perhaps:
>      >>    For example, when the sender is application
>      >>    limited and only sends small amounts of application traffic
>      >>    periodically, where the periodicity is longer than the RTT, spin bit
>      >>    measurement provides information about the application period rather
>      >>    than network RTT.
>      >> -->
>      > We should pluralize measurements, though; NEW:
>      >
>      > For example, if the sender only sends small amounts of application traffic
>      > periodically, where the periodicity is longer than the RTT, spin bit
>      > measurements provide information about the application period rather
>      > than network RTT.
>      >
>      >> 12) <!-- [rfced] Section 3.8.2: In the following, does "QoF" mean "quality of flow"?
>      >>
>      >> Original:
>      >>    for example, QoF [TMA-QOF] rejects component RTTs
>      >>    significantly higher than RTTs over the history of the flow.
>      >> -->
>      > QoF is a proper name.
>      >
>      >> 13) <!-- [rfced] Section 4.2: We suggest rephrasing this sentence for easier comprehension. Does the suggested text change the meaning of the original sentence?
>      >>
>      >> Original:
>      >>    The recommendation is therefore that, even when lower state timeouts
>      >>    are used for other UDP traffic, a state timeout of at least two
>      >>    minutes ought to be used for QUIC traffic.
>      >>
>      >> Perhaps:
>      >>    Therefore, it is recommended that a state timeout of at least two
>      >>    minutes be used for QUIC traffic even when lower state timeouts are
>      >>    used for other UDP traffic.
>      >> -->
>      > Reordering for more clarity, we have NEW:
>      >
>      > Therefore, a state timeout of at least two minutes is recommended for QUIC traffic, even when lower state timeouts are used for other UDP traffic.
>      >
>      >> 14) <!-- [rfced] Section 4.5: We have updated the following. Please let us know if any changes are necessary:
>      >>
>      >> Original:
>      >>    [RFC4787] describes possible packet filtering behaviors that relate
>      >>    to NATs but is often also used is other scenarios where packet
>      >>    filtering is desired.  Though the guidance there holds, a
>      >>    particularly unwise behavior admits a handful of UDP packets and then
>      >>    makes a decision to whether or not filter later packets in the same
>      >>    connection.
>      >>
>      >> Current (changing the second "is" to "in" in the first sentence and changing "makes a decision to whether or not filter" to "decides whether or not to filter" in the second):
>      >>    [RFC4787] describes possible packet-filtering behaviors that relate
>      >>    to NATs but are often also used in other scenarios where packet
>      >>    filtering is desired.  Though the guidance there holds, a
>      >>    particularly unwise behavior admits a handful of UDP packets and then
>      >>    decides whether or not to filter later packets in the same
>      >>    connection.
>      >> -->	
>      > This edit is good.
>      >
>      >> 15) <!-- [rfced] Section 4.7 and Informative References: We have updated the term "syncookies" to "SYN cookies" and have corrected its reference. Please let us know of any concerns:
>      >>
>      >> Original:
>      >>    Beyond in-network DDoS protection mechanisms, TCP syncookies
>      >>    [RFC4937] are a well-established method of mitigating some kinds of
>      >>    TCP DDoS attacks.  QUIC Retry packets are the functional analogue to
>      >>    syncookies, ...
>      >>
>      >>    [RFC4937]  Arberg, P. and V. Mammoliti, "IANA Considerations for PPP
>      >>               over Ethernet (PPPoE)", RFC 4937, DOI 10.17487/RFC4937,
>      >>               June 2007, <https://www.rfc-editor.org/info/rfc4937>.
>      >>
>      >> Current:
>      >>    Beyond in-network DDoS protection mechanisms, TCP SYN cookies
>      >>    [RFC4987] are a well-established method of mitigating some kinds of
>      >>    TCP DDoS attacks.  QUIC Retry packets are the functional analogue to
>      >>    SYN cookies, ...
>      >>
>      >>    [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
>      >>               Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
>      >>               <https://www.rfc-editor.org/info/rfc4987>.
>      >> -->
>      > This edit is good. Thanks for the catch!
>      >
>      >> 16) <!-- [rfced] Section 4.9: Should the instances of "PLPMTUD" in the following be "DPLPMTUD"?
>      >>
>      >> Original:
>      >>    Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by
>      >>    QUIC to probe for the supported PMTU.  PLPMTUD optionally uses ICMP
>      >>    messages (e.g., IPv6 Packet Too Big messages).  Given known attacks
>      >>    with the use of ICMP messages, the use of PLPMTUD in QUIC has been
>      >>    designed to safely use but not rely on receiving ICMP feedback
>      >> -->
>      > Yes, please change to DPLPMTUD. Thanks!
>      >
>      >> 17) <!-- [rfced] Terminology:
>      >>
>      >> a) Throughout the text, the following terms were used inconsistently. We have updated them to use the latter form. Please let us know if any changes are necessary:
>      >>
>      >>    Client Hello / ClientHello (to match RFC 9001)
>      >>    destination connection ID / Destination Connection ID (to match RFC 9000)
>      >>    length field / Length field (to match RFC 9000)
>      >>    key phase / Key Phase (as in the field, RFC 9001)
>      >>    packet number / Packet Number (as in the field, RFC 9000)
>      >>    Server Hello / ServerHello (to match RFC 9001)
>      >>    source connection ID / Source Connection ID (to match RFC 9000)
>      >>    Version 1 / version 1 (to match RFC 9000)
>      >>
>      >> b) In the text, the following terms were used consistently, but we have updated them to match the formatting used in normative references. Please let us know if any changes are necessary:
>      >>
>      >>    fixed bit / Fixed Bit (as in the field, RFC 9000)
>      >>    packet number length / Packet Number Length (as in the field, RFC 9000)
>      >>    token length / Token Length (as in the field, RFC 9000)
>      >> -->
>      > These edits are good.
>      >
>      >> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed.
>      >> -->
>      > No changes are needed; our CI pipeline ensures checks run at each commit.
>      >
>      >> 19) <!-- [rfced] Informative References: The links for the PDF and slides on the [TMA-QOF] webpage lead to 404: Not Found Errors. How may we update the reference? We have found a DOI and available PDF on link.springer.com:
>      >>
>      >> Current:
>      >>    [TMA-QOF]  Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data
>      >>               Integrity Signals for Passive Measurement", Sixth
>      >>               International Workshop on Traffic Measurement and
>      >>               Analysis, April 2014,
>      >>               <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3fd835963da2b2cf&q=1&e=7c63010f-c7ce-4767-967e-10ef133e277e&u=https%3A%2F%2Ftrammell.ch%2Fpublication%2Fqof-tma-2014>.
>      >>
>      >> Perhaps:
>      >>    [TMA-QOF]  Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data
>      >>               Integrity Signals for Passive Measurement", Traffic Measurement
>      >>               and Analysis, TMA 2014, Lecture Notes in Computer Science,
>      >>               vol. 8406, pp. 15-25, April 2014,
>      >>               <https://link.springer.com/chapter/10.1007/978-3-642-54999-1_2>.
>      >> -->
>      > Yes, this is a better link, please update.
>      >
>      >> 20) <!-- [rfced] Informative References: The target URL for [IPIM] leads to a page titled "Principles for Measurability in Protocol Design". Is this the correct link for the reference that is listed in the document? Or does the title of this reference need to be updated?
>      >>
>      >> Original:
>      >>    [IPIM]     Allman, M., Beverly, R., and B. Trammell, "In-Protocol
>      >>               Internet Measurement (arXiv preprint 1612.02902)", 9
>      >>               December 2016, <https://arxiv.org/abs/1612.02902>.
>      >> -->
>      > The link is correct, the proper title is "Principles for Measurability in Protocol Design”; please update it. Thanks!
>      >
>      >
>      > Modulo the updates in this email, I approve of the publication of this draft as an RFC.
>      >
>      > Many thanks, cheers,
>      >
>      > Brian
>      >
>      >> Thank you.
>      >>
>      >> RFC Editor/mc/jm
>      >>
>      >>
>      >> On 9/12/22 4:53 PM, [e-mail] wrote:
>      >>
>      >> *****IMPORTANT*****
>      >>
>      >> Updated 2022/09/12
>      >>
>      >> 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://authors.ietf.org/rfcxml-vocabulary>.
>      >>
>      >> *  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 using ‘REPLY ALL’ as all
>      >> the parties CCed on this message need to see your changes. The parties
>      >> include:
>      >>
>      >>    *  your coauthors
>      >>
>      >>    *  [e-mail] (the RPC team)
>      >>
>      >>    *  other document participants, depending on the stream (e.g.,
>      >>       IETF Stream participants are your working group chairs, the
>      >>       responsible ADs, and the document shepherd).
>      >>
>      >>    *  [e-mail], which is a new archival mailing list
>      >>       to preserve AUTH48 conversations; it is not an active discussion
>      >>       list:
>      >>
>      >>      *  More info:
>      >>         https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>      >>
>      >>      *  The archive itself:
>      >>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>      >>
>      >>      *  Note: If only absolutely necessary, you may temporarily opt out
>      >>         of the archiving of messages (e.g., to discuss a sensitive matter).
>      >>         If needed, please add a note at the top of the message that you
>      >>         have dropped the address. When the discussion is concluded,
>      >>         [e-mail] will be re-added to the CC list and
>      >>         its addition will be noted at the top of the message.
>      >>
>      >> You may submit your changes in one of two ways:
>      >>
>      >> 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 stating
>      >> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>      >> as all the parties CCed on this message need to see your approval.
>      >>
>      >>
>      >> Files
>      >> -----
>      >>
>      >> The files are available here:
>      >>    https://www.rfc-editor.org/authors/rfc9312.xml
>      >>    https://www.rfc-editor.org/authors/rfc9312.html
>      >>    https://www.rfc-editor.org/authors/rfc9312.pdf
>      >>    https://www.rfc-editor.org/authors/rfc9312.txt
>      >>
>      >> Diff file of the text:
>      >>    https://www.rfc-editor.org/authors/rfc9312-diff.html
>      >>    https://www.rfc-editor.org/authors/rfc9312-rfcdiff.html (side by side)
>      >>
>      >> Diff of the XML:
>      >>    https://www.rfc-editor.org/authors/rfc9312-xmldiff1.html
>      >>
>      >> The following files are provided to facilitate creation of your own
>      >> diff files of the XML.
>      >>
>      >> Initial XMLv3 created using XMLv2 as input:
>      >>    https://www.rfc-editor.org/authors/rfc9312.original.v2v3.xml
>      >>
>      >> XMLv3 file that is a best effort to capture v3-related format updates
>      >> only:
>      >>    https://www.rfc-editor.org/authors/rfc9312.form.xml
>      >>
>      >>
>      >> Tracking progress
>      >> -----------------
>      >>
>      >> The details of the AUTH48 status of your document are here:
>      >>    https://www.rfc-editor.org/auth48/rfc9312
>      >>
>      >> Please let us know if you have any questions.
>      >>
>      >> Thank you for your cooperation,
>      >>
>      >> RFC Editor
>      >>
>      >> --------------------------------------
>      >> RFC9312 (draft-ietf-quic-manageability-18)
>      >>
>      >> Title            : Manageability of the QUIC Transport Protocol
>      >> Author(s)        : M. Kühlewind, B. Trammell
>      >> WG Chair(s)      : Matt Joras, Lucas Pardue
>      >>
>      >> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>