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

[Jean Mahoney <[e-mail]>]

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
>