jiebi/TextFlow huggingface dataset:
Original text:
every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. <del> latency spin bit: the third most significant bit of first octet. However, the is only used in short packet headers.  There it will be set alternatingly to 0 or 1 by the endpoints such that tracking edge transistions can be used to passively monitor the connection RTT, see spin-usage for further details. </del>  header type: the long header has a 2 bit packet type field following the Header Form bit.  Header types correspond to stages

Reviewer comments:
Review and update text in -manageability to reflect BKK spin bit consensus: single spin bit is in the protocol spec now endpoints may opt out (discuss why; this is for any reason, not just proxies as suggested in ), endpoints should probabilistically out out to provide cover for endpoints opting out
I am working on this.
NAME what about having a privacy consideration section ?
I'm not sure this fits in the scope of the document: can you say more about what you propose to be in this section? The -manageability document is meant to be an independent user's guide to the wire image, so information on the spin bit here will be more about how to measure it, not additional guidelines on how to generate it and when not to (though such text might belong in -applicability) Please coordinate with NAME who will also be proposing text on spin measurement to bring over from draft-ietf-quic-spin-exp.
see PR
closed by merge of and

Revised text:
every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols.  <ins> latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further details. </ins> header type: the long header has a 2 bit packet type field following the Header Form bit.  Header types correspond to stages
Original text:
6. <del> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] </del>  7.

Reviewer comments:
This section was still empty so far. This PR also address issue .
This is related to quicwg/base-drafts and depends on the outcome there.
PR now indicated that the idle timeout could be exposed to the application. However, we should probably say a bit more what to do with it. I guess the minimum would be to say that the keep-alive frequency needs to be clearly smaller than the idle timeout, e.g. half the timeout. Is there anything more we could say? NAME NAME any thoughts? Or text you can provide?
PR provides some more guidance now but it still doesn't discuss suitable value or ranges. What values are used in current implementations? Should we say more?
See also PR
merged
This is good, modulo typos (all edits as suggestions)

Revised text:
6.  <ins> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code.  Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar capablities.  Usually application error codes are defined to be applicabile to all three frames. Alternatively, a QUIC connection will be silently closed by each endpoint separately after an idle timeout.  The idle timeout is announce for each endpoint during connection established and should be accessible by the application.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. </ins> 7.
Original text:
The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the <del> Connection ID is present and what length it has. </del>  4.2.

Reviewer comments:
At Gorry's suggestion I put the NAT guidance into a different draft: URL Sorry, I thought the notification went out automatically. Regardless, this change is fine.
The manageability draft should talk a little bit about NATS for QUIC. The laziest thing to do is just continue to have NAT mapping be by 4-tuple, as it is today. This is actually fine. However, someone might attempt to be clever and use the CID as well. For example, client A and client B could share the same serverside address and port and the NAT can initially distinguish between the two because they have different CIDs. This appears to save address space, but doesn't actually work because the server could switch to a new client connection ID. In this case, the NAT won't be able to determine which client to route to.
I think it's also worth mentioning that using just the CID only is similarly broken, the fundamental underlying concept here is that subsequent CIDs are exchanged in a manner that the NAT cannot see -- the only time it's okay to use CIDs is if you're colluding with one of the endpoints, as in QUIC LB.
At least recommend to use longer binding lifetimes for identified QUIC connections?
See PR
Fixed in this doc by
Looks good to me. It might be worth adding a bit more (see my detailed comment).

Revised text:
The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the  <ins> Connection ID is present and what length it has.  However, Connection IDs may be renegotiated during a connection, and this renegotiation is not visible to the path.  Keying state off the Connection ID may therefore cause undetectable and unrecoverable loss of state in the middle of a connection.  Use of Connection ID specifically discouraged for NAT applications. </ins> 4.2.
Original text:
routability.  Therefore changing these information will also cause the connection to fail.  3. This section addresses the different kinds of observations and

Reviewer comments:
when merged.
See also issue quicwg/base-drafts
Good Strategy probably is to move quickly to new version and/or deploy draft versions in order to keep the version number field as dynamic as possible. However, if there will be ossification there is probably still a possibility to implement some kind of alternate version negotiation in the encrypted part of the packet and pretend on the outside to use the supported version (similar as TLS1.3 does); of course there is a performance/overhead trade-off. With the uncertainty about what will happen in respect to ossification, it might not be worth is to try and solve the problem now and pay the complexity up front.
does not appear as though the discussion on the list has converged yet; will wait to see at happens in the base drafts before addressing this one in ops.
Consensus to handle "weak" version ossification via a mechanism in the transport; holding this issue open until that converges, but probably not useful to have text in manageability.
This converged in Singapore to no-action in v1.
Fixed by
My comments left the lines >80 characters, but otherwise LGI'm wondering if we should use even stronger language; not that anything can really enforce it.

Revised text:
routability.  Therefore changing these information will also cause the connection to fail. <ins> QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed in the Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the multi-year timeframe so therefore not recommended. </ins> 3. This section addresses the different kinds of observations and
Original text:
ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis.  12. Note to RFC Editor: Please replace all occurrences of "[[this

Reviewer comments:
Not a grave issue, but it's a leak of information that can be reduced to leaking unexpected reboots vs. leaking any reboot by being aware of it.
Thanks NAME , I am just confused by the term "clean shutdown" here. What do you mean by that? If I understand correctly the rest of your text, you are suggesting that to avoid leaking information about accidental reboots, the device keeps track of the node's state constantly, so that when an accidental reboot happens, the node can re-instate the right seq. When does clean shutdown come into the picture?
Typical devices can not tolerate the flash wear of writing the sequence number state on any package transmission (that's why there's the "Seq + K" part in 6.3.1), and that limitation won't go away just because it has privacy consequences. Accidental reboots will thus be leaked, but deliberate ones can be hidden by storing the fine-grained seqno state on flash. For example: Initial boot, everything is 0 Before sending package 1, write "seqno=1000" Send 999 more packages w/o writing Before sending package 1001, write "seqno=2000" Send some more packages w/o writing Zap, reboot! Before sending seqno 2001, write "seqno=3000" (this is a hard to prevent leak) Send 49 more packages Shutdown requested, write "seqno=2050" Reboot Before sending seqno=2051, write "seqno=3050" (no reboot leaked)

Revised text:
ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. <ins> Using the mechanisms described in seqno-replay-state reveals when a device goes through a reboot.  This can be mitigated by the device storing the precise state of sender sequence number and recipient replay window on a clean shutdown. </ins> 12. Note to RFC Editor: Please replace all occurrences of "[[this
Original text:
The presence of the Object-Security option, both in requests and responses, is expressed in an HTTP header field named Object-Security <del> in the mapped request or response.  The value of the field is the value of the Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding).  The value of the payload is the OSCORE payload oscore-payl, also base64url-encoded without padding. </del>  Example:

Reviewer comments:
As suggested in
Need to update example as well
Not on expert on HTPP header formats, but are single quotes '' correct? I think I have only seen double quotes "" in HTTP.
should be fixed now
"The value of the payload" It is called body in HTTP
Jim suggested to not have an empty HTTP header (legal but likely to create problems), instead use: ""

Revised text:
The presence of the Object-Security option, both in requests and responses, is expressed in an HTTP header field named Object-Security  <ins> in the mapped request or response.  The value of the field is: "" (empty string) if the CoAP Object-Security option is empty, or the value of the CoAP Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding). The value of the body is the OSCORE payload oscore-payl. </ins> Example:
Original text:
Readers are expected to be familiar with the terms and concepts described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE <del> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl, and constrained environments RFC7228. </del>  The term "hop" is used to denote a particular leg in the end-to-end path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or

Reviewer comments:
I believe this is about the minimum change that we can make to avoid the need for a normative reference to draft-ietf-cbor-cddl, which might hold up the document in the RFC editor queue.
Thank you NAME the only thing I can think of is adding a reference to CBOR in the appendix too, but that's it.

Revised text:
Readers are expected to be familiar with the terms and concepts described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE  <ins> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl as summarized in cddl- sum, and constrained environments RFC7228. </ins> The term "hop" is used to denote a particular leg in the end-to-end path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or
Original text:
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the <del> Partial IV (Sequence Number) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </del>  Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the Compute the COSE object as specified in sec-obj-cose the AEAD nonce is created by XORing the Sender IV (context IV) <del> with the Sender Sequence Number (partial IV). </del>  If the block option is used, the AAD includes the AEAD Tag from the previous block sent (from the second block and following)

Reviewer comments:
This should fix issue
As per Christian Amsüss' message from 2017-01-04 we should clarify how we expect implementers to map sequence numbers to partial IV's. I think that network-byte order is a good way.

Revised text:
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the  <ins> Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). </ins> Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the Compute the COSE object as specified in sec-obj-cose the AEAD nonce is created by XORing the Sender IV (context IV)  <ins> with the Sender Sequence Number in network byte order (partial IV). </ins> If the block option is used, the AAD includes the AEAD Tag from the previous block sent (from the second block and following)
Original text:
length, or three octets in length.  The length of the OHB indicates what data is contained in the extension. <del> If the OHB is one octet in length, it contains both the original X bit and PT field value.  In this case, the OHB has this form: </del>  If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form: <del> If the OHB is three octets in length, it contains the original X bit, PT field value, and RTP packet sequence number.  In this case, the OHB has this form: </del>  If an MDD modifies an original RTP header value, the MDD MUST include <del> the OHB extension to reflect the changed value.  If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB.  To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </del>  5.

Reviewer comments:
2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.

Revised text:
length, or three octets in length.  The length of the OHB indicates what data is contained in the extension.  <ins> If the OHB is one octet in length, it contains the original PT field value.  In this case, the OHB has this form: Note that "R" indicates a reserved bit that MUST be set to zero when sending a packet and ignored upon receipt. </ins> If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form:  <ins> If the OHB is three octets in length, it contains the original PT field value and RTP packet sequence number.  In this case, the OHB has this form: </ins> If an MDD modifies an original RTP header value, the MDD MUST include  <ins> the OHB extension to reflect the changed value, setting the X bit in the RTP header to 1 if no header extensions were originally present. If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB. To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </ins> 5.
Original text:
typically different than the HBH key for the incoming packet. The receiver can check the authentication of the initial and extra <del> envelope information.  This, along with the OBH, is used to construct </del>  a synthetic packet that is should be identical to one the sender created and the receiver can check that it is identical and then decrypt the original payload.

Reviewer comments:
Make sure double can work with future FEC schemes that do HBH repair and have state that could be corrupted by non authenticated packets
resolved in latest draft

Revised text:
typically different than the HBH key for the incoming packet. The receiver can check the authentication of the initial and extra  <ins> envelope information.  This, along with the OHB, is used to construct </ins> a synthetic packet that is should be identical to one the sender created and the receiver can check that it is identical and then decrypt the original payload.
Original text:
The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension.  5.3. When using EKT with DTLS-SRTP, the negotiation to use EKT is done at

Reviewer comments:
EKT draft should make a clear naming difference between the message form TLS server / client and the the thing that goes at end of RTP packet Also clear up figure 5. First packets go to KD, last several packets go elsewhere
The PR fixes the figure. I looked at the naming and I don't think there is anything to be done to make it clearer.

Revised text:
The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. <ins> Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the oter packets will be relayed by the Media Distributor to the Key Distributor. </ins> 5.3. When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
Original text:
7.1. <del> TODO - Add text to explain how to use RTX as described in Option A of slides presented at IETF 99. </del>  7.2.

Reviewer comments:
This is not ready to merge yet but can be used to start discussion on RTX text
Higher level question .. Should it help having a generic repair processing section that identifies the sender and receiver behavior. It could be informative and can reflect the pictures from the presentation. Thoughts ?
I think as confusing as the whole topic is/was to us experts I think we should have a paragraph explaining that any of the repairs are effectively a triple encryption.
looks good

Revised text:
7.1.  <ins> When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be encrypted using a crypto context with a null E2E key. </ins> 7.2.
Original text:
provide keying material for the outer (hop-by-hop) algorithm is to use I-D.ietf-perc-dtls-tunnel.  4. The Original Header Block (OHB) contains the original values of any

Reviewer comments:
Right now, the SRTP KDF destroys the separation between the inner and outer halves of the master key, which means that EKT can't set the E2E key without also resetting the HBH key. This PR moves from the default SRTP KDF to use a "split PRF" that preserves the separation between the E2E and HBH halves of the key.
LGTM

Revised text:
provide keying material for the outer (hop-by-hop) algorithm is to use I-D.ietf-perc-dtls-tunnel. <ins> 3.1. In order to allow the inner and outer keys to be managed independently via the master key, the transforms defined in this document MUST be used with the following PRF, which preserves the separation between the two halves of the key: Here represents the default SRTP PRF RFC3711, represents the first half of the key, and represents the second half of the key. </ins> 4. The Original Header Block (OHB) contains the original values of any
Original text:
6.  TODO IANA registry for Message Type  TODO IANA registry EKT ciphers. <del> 6.1. </del>  IANA is requested to add "srtp_ekt_key_transport" as an new extension name to the "ExtensionType Values" table of the "Transport Layer Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". <del> 6.2. </del>  IANA is requested to add "srtp_ekt_message" as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer

Reviewer comments:
Should be in EKTkey not where it is. Should have text that when grt new KEK, need to wait X then start using new SRTP master key

Revised text:
6. <ins> 6.1. </ins> TODO IANA registry for Message Type <ins> 6.2. </ins> TODO IANA registry EKT ciphers.  <ins> 6.3. </ins> IANA is requested to add "srtp_ekt_key_transport" as an new extension name to the "ExtensionType Values" table of the "Transport Layer Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus".  <ins> 6.4. </ins> IANA is requested to add "srtp_ekt_message" as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer
Original text:
5.3. <del> The Key Distributor needs to know what endpoints are to being added to in a given conference resource.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </del>  6.

Reviewer comments:
Fixed typos/deleted extra words in the Conf Id section.
LGTMlooks good.

Revised text:
5.3.  <ins> The Key Distributor needs to know what endpoints are being added to a given conference.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </ins> 6.