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

[Jean Mahoney <[e-mail]>]

Hi Brian,

On 9/22/22 10:59 AM, Brian Trammell (IETF) wrote:
> hi Jean,
>
> Oops, many thanks for the catch! Please use "Google Switzerland GmbH".
[JM] Done!
https://www.rfc-editor.org/authors/rfc9308-lastrfcdiff.html

We'll continue moving this document and RFC 9312 forward in the 
publication process.

Best regards,
Jean


>
> Thanks, cheers,
>
> Brian
>
>> On 22 Sep 2022, at 17:36, Jean Mahoney <[e-mail]> wrote:
>>
>> Hi Mirja and Brian,
>>
>> We have updated the [QUIC-MANAGEABILITY] reference to point to RFC 9312:
>>
>>     https://www.rfc-editor.org/authors/rfc9308-lastrfcdiff.html
>>
>> Brian,
>>
>> We noticed that your affiliation is specified as the following. How may we make these consistent?
>>
>>     RFC 9308:  Google
>>
>> https://www.rfc-editor.org/authors/rfc9308.txt
>>
>>
>>     RFC 9312:  Google Switzerland GmbH
>>
>> https://www.rfc-editor.org/authors/rfc9312.txt
>>
>>
>> Best regards,
>> RFC Editor/jm
>>
>> On 9/22/22 8:35 AM, Mirja Kuehlewind wrote:
>>> Hi Jean,
>>>
>>> yes, please publish these drafts together and update the reference accordingly. As you can see, I also just approved the updates to the manageability draft.
>>>
>>> Thanks!
>>> Mirja
>>>
>>>
>>> On 21.09.22, 22:59, "Jean Mahoney" <[e-mail]> wrote:
>>>
>>>      Hi Mirja,
>>>
>>>      We have noted your approval on the AUTH48 status page:
>>>
>>>          https://www.rfc-editor.org/auth48/rfc9308
>>>
>>>      We can now move this document forward in the publication process because
>>>      it does not have a normative reference to [QUIC-MANAGEABILITY], which is
>>>      currently listed as an I-D in the Informative References section.
>>>
>>>      However, would you like to wait for RFC 9312 to complete AUTH48 so that
>>>      the [QUIC-MANAGEABILITY] reference can be updated to point to the RFC?
>>>
>>>      Best regards,
>>>      Jean
>>>
>>>      On 9/21/22 8:32 AM, Mirja Kuehlewind wrote:
>>>      > Hi Jean,
>>>      >
>>>      > thanks all changse look good to me! Thanks!
>>>      >
>>>      > Mirja
>>>      >
>>>      >
>>>      >
>>>      > On 21.09.22, 00:13, "Jean Mahoney" <[e-mail]> wrote:
>>>      >
>>>      >      Brian,
>>>      >
>>>      >      Thank you for your response and your approval. We have noted your
>>>      >      approval on the AUTH48 status page:
>>>      >
>>>      >          https://www.rfc-editor.org/auth48/rfc9308
>>>      >
>>>      >        We have updated the document with your feedback:
>>>      >
>>>      >      https://www.rfc-editor.org/authors/rfc9308-lastrfcdiff.html (these
>>>      >      changes side by side)
>>>      >
>>>      >          https://www.rfc-editor.org/authors/rfc9308.txt
>>>      >          https://www.rfc-editor.org/authors/rfc9308.pdf
>>>      >          https://www.rfc-editor.org/authors/rfc9308.html
>>>      >          https://www.rfc-editor.org/authors/rfc9308.xml
>>>      >          https://www.rfc-editor.org/authors/rfc9308-diff.html (all changes
>>>      >      inline)
>>>      >          https://www.rfc-editor.org/authors/rfc9308-rfcdiff.html (all changes
>>>      >      side by side)
>>>      >          https://www.rfc-editor.org/authors/rfc9308-auth48diff.html (all
>>>      >      AUTH48 changes inline)
>>>      >          https://www.rfc-editor.org/authors/rfc9308-xmldiff1.html (XML
>>>      >          https://www.rfc-editor.org/authors/rfc9308-xmldiff2.html
>>>      >
>>>      >      Please note that we have updated the formatting and placement of the
>>>      >      Contributors section (apologies for not catching that sooner).
>>>      >
>>>      >      We'll await word from Mirja regarding other AUTH48 feedback and/or approval.
>>>      >
>>>      >      Best regards,
>>>      >      RFC Editor/jm
>>>      >
>>>      >      On 9/20/22 2:14 PM, Brian Trammell (IETF) wrote:
>>>      >      > Greetings,
>>>      >      >
>>>      >      > Replies inline
>>>      >      >
>>>      >      >> On 25 Aug 2022, at 20:21, [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. -->
>>>      >      > QUIC, application protocol mapping, deployment
>>>      >      >
>>>      >      >> 2) <!-- [rfced] Section 2: FYI, we have expanded TAPS in the following:
>>>      >      >>
>>>      >      >> Original:
>>>      >      >>    The IETF TAPS specifications [I-D.ietf-taps-arch] describe a system
>>>      >      >>    with a common API for multiple protocols.
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>   The IETF Transport Services (TAPS) specifications [TAPS-ARCH] describe
>>>      >      >>   a system with a common API for multiple protocols.
>>>      >      >> -->
>>>      >      > This edit is fine
>>>      >      >
>>>      >      >> 3) <!-- [rfced] Section 3.1: We're having difficulty parsing the following sentence. Does rewriting the last part of the sentence improve readability?
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    In some cases, it might be sufficient to limit application data sent
>>>      >      >>    in 0-RTT to that which only causes actions at a server that are known
>>>      >      >>    to be free of lasting effect.
>>>      >      >>
>>>      >      >> Perhaps (clarifying that the data should not cause lasting effects):
>>>      >      >>    In some cases, it might be sufficient to limit the application data sent
>>>      >      >>    in 0-RTT to data that does not cause actions with lasting effects at a
>>>      >      >>    server.
>>>      >      >> -->
>>>      >      > The suggested edit is good.
>>>      >      >
>>>      >      >> 4) <!-- [rfced] Section 3.2: This is the one instance of "NAT address rebinding", whereas the other instances are simply "NAT rebinding". Please review these occurrences and let us know if/how they may be made consistent.
>>>      >      >>
>>>      >      >> Original:
>>>      >      >>    By using a connection ID, QUIC is designed to be robust to NAT address
>>>      >      >>    rebinding after a timeout.
>>>      >      >> -->
>>>      >      > Suggest cutting “address”:
>>>      >      >
>>>      >      > NEW:
>>>      >      >
>>>      >      > By using a connection ID, QUIC is designed to be robust to NAT
>>>      >      > rebinding after a timeout.
>>>      >      >
>>>      >      >> 5) <!-- [rfced] Section 4.4: We found these sentences in the third paragraph difficult to parse because of the number of noun modifiers.
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    The size and rate of transport flow control credit updates can affect
>>>      >      >>    performance....
>>>      >      >>
>>>      >      >>    Some implementations might have independent transport-layer and
>>>      >      >>    application-layer receive buffers...
>>>      >      >>
>>>      >      >>    However, a common flow control implementation technique is to extend
>>>      >      >>    credit...
>>>      >      >>
>>>      >      >> Perhaps (splitting apart the descriptions):
>>>      >      >>    The size and rate of updates to flow control credit can affect
>>>      >      >>    performance.... .
>>>      >      >>
>>>      >      >>    Some implementations might have independent receive buffers at the
>>>      >      >>    transport layer and application layer....
>>>      >      >>
>>>      >      >>    However, a common implementation technique is to extend flow control
>>>      >      >>    credit...
>>>      >      >> -->
>>>      >      > All of these suggested edits are good.
>>>      >      >
>>>      >      >> 6) <!-- [rfced] Section 4.5: Are there some words missing in the example given in the following sentence?
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    An application that uses QUIC and communicates a cumulative stream
>>>      >      >>    limit might require the connection to be closed before the limit is
>>>      >      >>    reached, e.g., to stop the server to perform scheduled maintenance.
>>>      >      >>
>>>      >      >> Perhaps (adding "in order"):
>>>      >      >>    An application that uses QUIC and communicates a cumulative stream
>>>      >      >>    limit might require the connection to be closed before the limit is
>>>      >      >>    reached, e.g., to stop the server in order to perform scheduled
>>>      >      >>    maintenance.
>>>      >      >> -->
>>>      >      > This suggested edit is good.
>>>      >      >
>>>      >      >> 7) <!-- [rfced] Section 5: We're having difficulty with the following sentence because we do not see "DATA frames" in RFC 9000. We do see MAX_DATA and MAX_STREAM_DATA frames, but Section 13 discusses STREAM frames. Also, should "packets ... frames" be "packets' ... frames"? Please let us know how we may update this sentence.
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    By default, many implementations will try to maximally pack QUIC
>>>      >      >>    packets DATA frames from one or more streams to minimize bandwidth
>>>      >      >>    consumption and computational costs (see Section 13 of [QUIC]).
>>>      >      >>
>>>      >      >> -->
>>>      >      > I believe we misspelled “STREAM” here.
>>>      >      >
>>>      >      > NEW:
>>>      >      >
>>>      >      > By default, many implementations will try to pack STREAM frames from
>>>      >      > from one or more streams into each QUIC packet, in order to minimize
>>>      >      > bandwidth consumption and computational costs (see Section 13 of [QUIC]).
>>>      >      >
>>>      >      >
>>>      >      >> 8) <!-- [rfced] Section 8: Does rewording the following sentence improve readability?
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    For applications with a fallback to TCP that do not already have an
>>>      >      >>    alternate mapping to UDP, usually the registration (if necessary) and
>>>      >      >>    use of the UDP port number corresponding to the TCP port already
>>>      >      >>    registered for the application is appropriate.
>>>      >      >>
>>>      >      >> Perhaps (making "application" single, more clearly stating what is usually appropriate):
>>>      >      >>    For an application with a fallback to TCP that does not already have an
>>>      >      >>    alternate mapping to UDP, it is usually appropriate to register (if
>>>      >      >>    necessary) and use of the UDP port number corresponding to the TCP
>>>      >      >>    port already registered for the application.
>>>      >      >> -->
>>>      >      > NEW:
>>>      >      >
>>>      >      > For an application with a fallback to TCP that does not already have an
>>>      >      > alternate mapping to UDP, it is usually appropriate to register (if
>>>      >      > necessary) and use the UDP port number corresponding to the TCP
>>>      >      > port already registered for the application.
>>>      >      >
>>>      >      >
>>>      >      > (there’s a spurious “of”: “use of the UDP port…” -> “use the UDP port...”.)
>>>      >      >
>>>      >      >
>>>      >      >> 9) <!-- [rfced] Section 8.1: Would you like to provide a reference for memcached?
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    For example, these source ports are associated with
>>>      >      >>    applications known to be vulnerable to reflection attacks often due
>>>      >      >>    to server misconfiguration:
>>>      >      >>
>>>      >      >>    *  port 53 - DNS [RFC1034]
>>>      >      >>
>>>      >      >>    *  port 123 - NTP [RFC5905]
>>>      >      >>
>>>      >      >>    *  port 1900 - SSDP [SSDP]
>>>      >      >>
>>>      >      >>    *  port 5353 - mDNS [RFC6762]
>>>      >      >>
>>>      >      >>    *  port 11211 - memcached
>>>      >      >> -->
>>>      >      > Nope, the port is registered with IANA without reference. However, the service name is “memcache”, not “memcached”, so let’s reference by service name.
>>>      >      >
>>>      >      >> 10) <!-- [rfced] Section 11.2: FYI, we replaced the CID acronym, which is not used elsewhere, with "Connection ID" for clarity. Please let us know if there are any objections.
>>>      >      >>
>>>      >      >> Original:
>>>      >      >>    Analysis of the lifetimes of six-tuples (source and destination
>>>      >      >>    addresses as well as the migrated CID) may expose these links anyway.
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    Analysis of the lifetimes of 6-tuples (source and destination
>>>      >      >>    addresses as well as the migrated Connection ID) may expose these
>>>      >      >>    links anyway.
>>>      >      >> -->
>>>      >      > This edit is good.
>>>      >      >
>>>      >      >> 11) <!-- [rfced] Section 11.2: Does removing redundant wording improve the readability of the following?
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    Conversely, in the opposite limit where every server handles multiple
>>>      >      >>    simultaneous migrations, even an exposed server mapping may be
>>>      >      >>    insufficient information.
>>>      >      >>
>>>      >      >> Perhaps:
>>>      >      >>    Conversely, when every server handles multiple
>>>      >      >>    simultaneous migrations, even an exposed server mapping may be
>>>      >      >>    insufficient information.
>>>      >      >> -->
>>>      >      > Yes, the suggested edit is good.
>>>      >      >
>>>      >      >> 12) <!-- [rfced] Section 11.3: RFC 5077 has been obsoleted by RFC 8446. How may we update the following cross reference?
>>>      >      >>
>>>      >      >> Original:
>>>      >      >>    Section 4 of [RFC5077] describes an example approach for constructing
>>>      >      >>    TLS resumption tickets that can be also applied for validation tokens,
>>>      >      >>    however, the use of more modern cryptographic algorithms is highly
>>>      >      >>    recommended.
>>>      >      >>
>>>      >      >> —>
>>>      >      > I believe the right thing to do here is not to update the cross-reference, as we're pointing out that the
>>>      >      > TLS session ticket example (removed from 8446 as far as I can tell) is useful guidance for building validation tokens.
>>>      >      >
>>>      >      > I would suggest some clarifying text here to note that we do, indeed, know that we're citing an obsolete RFC:
>>>      >      >
>>>      >      > NEW:
>>>      >      >
>>>      >      > The approach described in Section 4 of RFC5077 for constructing
>>>      >      > TLS resumption tickets provides an example that can also be applied to
>>>      >      > validation tokens. However, the use of more modern cryptographic algorithms
>>>      >      > than those presented in this example is highly recommended.
>>>      >      >
>>>      >      >> 13) <!-- [rfced] Section 16: Does the following rewording improve the readability of the sentence?
>>>      >      >>
>>>      >      >> Current:
>>>      >      >>    This document has no actions for IANA; however, note that Section 8
>>>      >      >>    recommends that application bindings to QUIC for applications using
>>>      >      >>    TCP register UDP ports analogous to their existing TCP registrations.
>>>      >      >>
>>>      >      >> Perhaps:
>>>      >      >>    This document has no actions for IANA; however, note that Section 8
>>>      >      >>    recommends that an application that has already registered a TCP port
>>>      >      >>    but wants to specify QUIC as a transport should register a UDP port
>>>      >      >>    analogous to their existing TCP registration.
>>>      >      >> -->
>>>      >      > Yes, this edit is good.
>>>      >      >
>>>      >      >> 14) <!-- [rfced] Terminology: We have made the following updates throughout the text. Please let us know if any changes are necessary.
>>>      >      >>
>>>      >      >> a) The following terms were used inconsistently. We have chosen the latter form:
>>>      >      >>
>>>      >      >>    four-tuple / 4-tuple
>>>      >      >>    five-tuple / 5-tuple
>>>      >      >>    six-tuple / 6-tuple
>>>      >      >>    application level / application layer
>>>      >      >>    transport level / transport layer
>>>      >      >>    Zero RTT / 0-RTT
>>>      >      >>
>>>      >      >>
>>>      >      >> b) Although the following term was formatted consistently, we have updated it to match other RFCs:
>>>      >      >>
>>>      >      >>    DiffServ / Diffserv (RFC 7657)
>>>      >      >> -->
>>>      >      > These edits are good.
>>>      >      >
>>>      >      >
>>>      >      >> 15) <!-- [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.
>>>      >      >> -->
>>>      >      > Inclusive language checks are integrated into the CI pipeline used to build the document, and have addressed issues flagged by that check from time to time. A final check of the document revealed no issues.
>>>      >      >
>>>      >      >
>>>      >      > Modulo changes in this message, I approve this RFC for publication.
>>>      >      >
>>>      >      > Thanks, cheers,
>>>      >      >
>>>      >      > Brian
>>>      >      >
>>>      >      >
>>>      >      >> Thank you.
>>>      >      >>
>>>      >      >> RFC Editor/st/jm
>>>      >      >>
>>>      >      >>
>>>      >      >> On 8/25/22 1:17 PM, [e-mail] wrote:
>>>      >      >>
>>>      >      >> *****IMPORTANT*****
>>>      >      >>
>>>      >      >> Updated 2022/08/25
>>>      >      >>
>>>      >      >> 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/rfc9308.xml
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308.html
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308.pdf
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308.txt
>>>      >      >>
>>>      >      >> Diff file of the text:
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308-diff.html
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308-rfcdiff.html (side by side)
>>>      >      >>
>>>      >      >> Diff of the XML:
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308-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/rfc9308.original.v2v3.xml
>>>      >      >>
>>>      >      >> XMLv3 file that is a best effort to capture v3-related format updates
>>>      >      >> only:
>>>      >      >>    https://www.rfc-editor.org/authors/rfc9308.form.xml
>>>      >      >>
>>>      >      >>
>>>      >      >> Tracking progress
>>>      >      >> -----------------
>>>      >      >>
>>>      >      >> The details of the AUTH48 status of your document are here:
>>>      >      >>    https://www.rfc-editor.org/auth48/rfc9308
>>>      >      >>
>>>      >      >> Please let us know if you have any questions.
>>>      >      >>
>>>      >      >> Thank you for your cooperation,
>>>      >      >>
>>>      >      >> RFC Editor
>>>      >      >>
>>>      >      >> --------------------------------------
>>>      >      >> RFC9308 (draft-ietf-quic-applicability-18)
>>>      >      >>
>>>      >      >> Title            : Applicability 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
>>>      >
>>>