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

["Brian Trammell (IETF)" <[e-mail]>]

hi Jean,

Oops, many thanks for the catch! Please use "Google Switzerland GmbH".

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
>>     >
>> 
>