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

[Mirja Kuehlewind <[e-mail]>]

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
    >