Diffs quicwg/base-drafts#4820

draft-ietf-quic-http.diff

diff --git a/draft-ietf-quic-http.txt b/draft-ietf-quic-http.mnot.txt
index 922b3770..fdd6cf0e 100644
--- a/draft-ietf-quic-http.txt
+++ b/draft-ietf-quic-http.mnot.txt
@@ -1032,23 +1032,23 @@ Table of Contents
    response is important.  The server SHOULD send PUSH_PROMISE frames
    prior to sending HEADERS or DATA frames that reference the promised
    responses.  This reduces the chance that a client requests a resource
    that will be pushed by the server.
 
    Due to reordering, push stream data can arrive before the
    corresponding PUSH_PROMISE frame.  When a client receives a new push
    stream with an as-yet-unknown Push ID, both the associated client
    request and the pushed request header fields are unknown.  The client
    can buffer the stream data in expectation of the matching
-   PUSH_PROMISE.  The client can use stream flow control (see section
-   4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server may
-   commit to the pushed stream.
+   PUSH_PROMISE.  The client can use stream flow control (see
+   Section 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server
+   may commit to the pushed stream.
 
    Push stream data can also arrive after a client has canceled a push.
    In this case, the client can abort reading the stream with an error
    code of H3_REQUEST_CANCELLED.  This asks the server not to transfer
    additional data and indicates that it will be discarded upon receipt.
 
    Pushed responses that are cacheable (see Section 3 of [CACHING]) can
    be stored by the client, if it implements an HTTP cache.  Pushed
    responses are considered successfully validated on the origin server
    (e.g., if the "no-cache" cache response directive is present; see
@@ -2292,21 +2292,21 @@ Table of Contents
    IETF and a contact of the HTTP working group (ietf-http-wg@w3.org).
 
 11.2.1.  Frame Types
 
    This document establishes a registry for HTTP/3 frame type codes.
    The "HTTP/3 Frame Type" registry governs a 62-bit space.  This
    registry follows the QUIC registry policy; see Section 11.2.
    Permanent registrations in this registry are assigned using the
    Specification Required policy ([RFC8126]), except for values between
    0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
-   Standards Action or IESG Approval as defined in Section 4.9 and 4.10
+   Standards Action or IESG Approval as defined in Sections 4.9 and 4.10
    of [RFC8126].
 
    While this registry is separate from the "HTTP/2 Frame Type" registry
    defined in [HTTP2], it is preferable that the assignments parallel
    each other where the code spaces overlap.  If an entry is present in
    only one registry, every effort SHOULD be made to avoid assigning the
    corresponding value to an unrelated operation.  Expert reviewers MAY
    reject unrelated registrations which would conflict with the same
    value in the corresponding registry.
 
@@ -2355,21 +2355,21 @@ Table of Contents
    assigned values.
 
 11.2.2.  Settings Parameters
 
    This document establishes a registry for HTTP/3 settings.  The
    "HTTP/3 Settings" registry governs a 62-bit space.  This registry
    follows the QUIC registry policy; see Section 11.2.  Permanent
    registrations in this registry are assigned using the Specification
    Required policy ([RFC8126]), except for values between 0x00 and 0x3f
    (in hexadecimal; inclusive), which are assigned using Standards
-   Action or IESG Approval as defined in Section 4.9 and 4.10 of
+   Action or IESG Approval as defined in Sections 4.9 and 4.10 of
    [RFC8126].
 
    While this registry is separate from the "HTTP/2 Settings" registry
    defined in [HTTP2], it is preferable that the assignments parallel
    each other.  If an entry is present in only one registry, every
    effort SHOULD be made to avoid assigning the corresponding value to
    an unrelated operation.  Expert reviewers MAY reject unrelated
    registrations which would conflict with the same value in the
    corresponding registry.
 
@@ -2408,21 +2408,21 @@ Table of Contents
    assigned values.
 
 11.2.3.  Error Codes
 
    This document establishes a registry for HTTP/3 error codes.  The
    "HTTP/3 Error Code" registry manages a 62-bit space.  This registry
    follows the QUIC registry policy; see Section 11.2.  Permanent
    registrations in this registry are assigned using the Specification
    Required policy ([RFC8126]), except for values between 0x00 and 0x3f
    (in hexadecimal; inclusive), which are assigned using Standards
-   Action or IESG Approval as defined in Section 4.9 and 4.10 of
+   Action or IESG Approval as defined in Sections 4.9 and 4.10 of
    [RFC8126].
 
    Registrations for error codes are required to include a description
    of the error code.  An expert reviewer is advised to examine new
    registrations for possible duplication with existing error codes.
    Use of existing registrations is to be encouraged, but not mandated.
    Use of values that are registered in the "HTTP/2 Error Code" registry
    is discouraged, and expert reviewers MAY reject such registrations.
 
    In addition to common fields as described in Section 11.2, this
@@ -2518,21 +2518,21 @@ Table of Contents
    assigned values.
 
 11.2.4.  Stream Types
 
    This document establishes a registry for HTTP/3 unidirectional stream
    types.  The "HTTP/3 Stream Type" registry governs a 62-bit space.
    This registry follows the QUIC registry policy; see Section 11.2.
    Permanent registrations in this registry are assigned using the
    Specification Required policy ([RFC8126]), except for values between
    0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
-   Standards Action or IESG Approval as defined in Section 4.9 and 4.10
+   Standards Action or IESG Approval as defined in Sections 4.9 and 4.10
    of [RFC8126].
 
    In addition to common fields as described in Section 11.2, permanent
    registrations in this registry MUST include the following fields:
 
    Stream Type:  A name or label for the stream type.
 
    Sender:  Which endpoint on an HTTP/3 connection may initiate a stream
       of this type.  Values are "Client", "Server", or "Both".
 

draft-ietf-quic-qpack.diff

diff --git a/draft-ietf-quic-qpack.txt b/draft-ietf-quic-qpack.mnot.txt
index 233857be..a8b195c9 100644
--- a/draft-ietf-quic-qpack.txt
+++ b/draft-ietf-quic-qpack.mnot.txt
@@ -184,21 +184,21 @@ Table of Contents
    capitals, as shown here.
 
    Definitions of terms that are used in this document:
 
    HTTP fields:  Metadata sent as part of an HTTP message.  The term
       encompasses both header and trailer fields.  Colloquially, the
       term "headers" has often been used to refer to HTTP header fields
       and trailer fields; this document uses "fields" for generality.
 
    HTTP field line:  A name-value pair sent as part of an HTTP field
-      section.  See Sections 6.3 and Section 6.5 of [SEMANTICS].
+      section.  See Sections 6.3 and 6.5 of [SEMANTICS].
 
    HTTP field value:  Data associated with a field name, composed from
       all field line values with that field name in that section,
       concatenated together with comma separators.
 
    Field section:  An ordered collection of HTTP field lines associated
       with an HTTP message.  A field section can contain multiple field
       lines with the same name.  It can also contain duplicate field
       lines.  An HTTP message can include both header and trailer
       sections.

draft-ietf-quic-recovery.diff

diff --git a/draft-ietf-quic-recovery.txt b/draft-ietf-quic-recovery.mnot.txt
index 48753cf6..84bb947f 100644
--- a/draft-ietf-quic-recovery.txt
+++ b/draft-ietf-quic-recovery.mnot.txt
@@ -198,21 +198,21 @@ Table of Contents
    In-flight packets:  Packets are considered in-flight when they are
       ack-eliciting or contain a PADDING frame, and they have been sent
       but are not acknowledged, declared lost, or discarded along with
       old keys.
 
 3.  Design of the QUIC Transmission Machinery
 
    All transmissions in QUIC are sent with a packet-level header, which
    indicates the encryption level and includes a packet sequence number
    (referred to below as a packet number).  The encryption level
-   indicates the packet number space, as described in Section 12.3 in
+   indicates the packet number space, as described in Section 12.3 of
    [QUIC-TRANSPORT].  Packet numbers never repeat within a packet number
    space for the lifetime of a connection.  Packet numbers are sent in
    monotonically increasing order within a space, preventing ambiguity.
    It is permitted for some packet numbers to never be used, leaving
    intentional gaps.
 
    This design obviates the need for disambiguating between
    transmissions and retransmissions; this eliminates significant
    complexity from QUIC's interpretation of TCP loss detection
    mechanisms.

draft-ietf-quic-tls.diff

diff --git a/draft-ietf-quic-tls.txt b/draft-ietf-quic-tls.mnot.txt
index 85bf39a2..5953f13e 100644
--- a/draft-ietf-quic-tls.txt
+++ b/draft-ietf-quic-tls.mnot.txt
@@ -794,21 +794,21 @@ Table of Contents
 
    Clients can store any state required for resumption along with the
    session ticket.  Servers can use the session ticket to help carry
    state.
 
    Session resumption allows servers to link activity on the original
    connection with the resumed connection, which might be a privacy
    issue for clients.  Clients can choose not to enable resumption to
    avoid creating this correlation.  Clients SHOULD NOT reuse tickets as
    that allows entities other than the server to correlate connections;
-   see Section C.4 of [TLS13].
+   see Appendix C.4 of [TLS13].
 
 4.6.  0-RTT
 
    The 0-RTT feature in QUIC allows a client to send application data
    before the handshake is complete.  This is made possible by reusing
    negotiated parameters from a previous connection.  To enable this,
    0-RTT depends on the client remembering critical parameters and
    providing the server with a TLS session ticket that allows the server
    to recover the same information.
 

draft-ietf-quic-transport.diff

diff --git a/draft-ietf-quic-transport.txt b/draft-ietf-quic-transport.mnot.txt
index cbfb7bf4..25872125 100644
--- a/draft-ietf-quic-transport.txt
+++ b/draft-ietf-quic-transport.mnot.txt
@@ -1171,21 +1171,21 @@ Table of Contents
    A blocked sender is not required to send STREAM_DATA_BLOCKED or
    DATA_BLOCKED frames.  Therefore, a receiver MUST NOT wait for a
    STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a
    MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the
    sender being blocked for the rest of the connection.  Even if the
    sender sends these frames, waiting for them will result in the sender
    being blocked for at least an entire round trip.
 
    When a sender receives credit after being blocked, it might be able
    to send a large amount of data in response, resulting in short-term
-   congestion; see Section 7.7 in [QUIC-RECOVERY] for a discussion of
+   congestion; see Section 7.7 of [QUIC-RECOVERY] for a discussion of
    how a sender can avoid this congestion.
 
 4.3.  Flow Control Performance
 
    If an endpoint cannot ensure that its peer always has available flow
    control credit that is greater than the peer's bandwidth-delay
    product on this connection, its receive throughput will be limited by
    flow control.
 
    Packet loss can cause gaps in the receive buffer, preventing the
@@ -4838,21 +4838,21 @@ Table of Contents
 
 14.4.  Sending QUIC PMTU Probes
 
    PMTU probes are ack-eliciting packets.
 
    Endpoints could limit the content of PMTU probes to PING and PADDING
    frames, since packets that are larger than the current maximum
    datagram size are more likely to be dropped by the network.  Loss of
    a QUIC packet that is carried in a PMTU probe is therefore not a
    reliable indication of congestion and SHOULD NOT trigger a congestion
-   control reaction; see Section 3, Bullet 7 of [DPLPMTUD].  However,
+   control reaction; see Section 3 of [DPLPMTUD], Bullet 7.  However,
    PMTU probes consume congestion window, which could delay subsequent
    transmission by an application.
 
 14.4.1.  PMTU Probes Containing Source Connection ID
 
    Endpoints that rely on the destination connection ID for routing
    incoming QUIC packets are likely to require that the connection ID be
    included in PMTU probes to route any resulting ICMP messages
    (Section 14.2.1) back to the correct endpoint.  However, only long
    header packets (Section 17.2) contain the Source Connection ID field,
@@ -7971,21 +7971,21 @@ Table of Contents
 22.4.  QUIC Frame Types Registry
 
    IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
    "QUIC" heading.
 
    The "QUIC Frame Types" registry governs a 62-bit space.  This
    registry follows the registration policy from Section 22.1.
    Permanent registrations in this registry are assigned using the
    Specification Required policy ([RFC8126]), except for values between
    0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using
-   Standards Action or IESG Approval as defined in Section 4.9 and 4.10
+   Standards Action or IESG Approval as defined in Sections 4.9 and 4.10
    of [RFC8126].
 
    In addition to the fields in Section 22.1.1, permanent registrations
    in this registry MUST include the following field:
 
    Frame Name:  A short mnemonic for the frame type.
 
    In addition to the advice in Section 22.1, specifications for new
    permanent registrations SHOULD describe the means by which an
    endpoint might determine that it can send the identified type of
@@ -8002,21 +8002,21 @@ Table of Contents
 
    IANA [SHALL add/has added] a registry for "QUIC Transport Error
    Codes" under a "QUIC" heading.
 
    The "QUIC Transport Error Codes" registry governs a 62-bit space.
    This space is split into three regions that are governed by different
    policies.  Permanent registrations in this registry are assigned
    using the Specification Required policy ([RFC8126]), except for
    values between 0x00 and 0x3f (in hexadecimal; inclusive), which are
    assigned using Standards Action or IESG Approval as defined in
-   Section 4.9 and 4.10 of [RFC8126].
+   Sections 4.9 and 4.10 of [RFC8126].
 
    In addition to the fields in Section 22.1.1, permanent registrations
    in this registry MUST include the following fields:
 
    Code:  A short mnemonic for the parameter.
 
    Description:  A brief description of the error code semantics, which
       MAY be a summary if a specification reference is provided.
 
    The initial contents of this registry are shown in Table 7.