jiebi/CodeConvo huggingface dataset:
Change:
Messages for streaming large data is also supported (see send- partial). <ins> Messages are sent on a Connection using the Send action: where messageData is the data object to send.  The optional messageContext parameter supports per-message properties and is described in message-props.  The optional endOfMessage parameter supports partial sending and is described in send-partial. </ins> 7.1. The most basic form of sending on a connection involves enqueuing a

Discussion:
Even though all the languages we want to support don't have convenient syntax for optional parameters to functions/methods, it would be nice to note that we intend for some parameters to not be mandatory on every call.
Looks good! This approach certainly clarifies things.LGTM except for the paragraph that I commented on; I'd just delete that.Fine withe mit (with some minor knit)
Change:
IETF 106 meeting: https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s <ins> MOPS Interim Meeting 2020-04-15: https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s IETF 108 meeting: https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s </ins> 2. 2.1.

Discussion:
I assume this is uncontroversial and am therefore just merging it, hearing no objections.
Change:
future TLS versions or new TLS extensions introduced in the future may vary this computation.) <del> An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer).  If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarily, replacing X25519 with X448, and ecdh_x25519 with ecdh_x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </del> <ins> An ECDHE key exchange using X25519 (curve x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer). If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448).  ECDHE for X448 works similarily, replacing X25519 with X448, and x25519 with x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result

Discussion:
ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me
Change:
signature algorithm pair that appears in that extension.  Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for <del> instance, an RSA key signed with a DSA key).  This is a departure from TLS 1.1, which required that the algorithms be the same. </del> <ins> instance, an RSA key signed with a DSA key). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such

Discussion:
These two notes are leftover from TLS 1.2 and not needed anymore in TLS 1.3. The first may not even be valid anymore.
Change:
procedures: the mapping of flow identifiers; and ensuring proper traffic treatment. <del> 7.1. </del> <ins> 7.3. </ins> A relay node that sends a DetNet IP flows over a DetNet MPLS network MUST map a single DetNet IP flow into a single app-flow and MUST

Discussion:
import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP
Change:
Spuriously declaring packets as lost leads to unnecessary retransmissions and may result in degraded performance due to the actions of the congestion controller upon detecting loss. <del> Implementations that detect spurious retransmissions and increase the reordering threshold in packets or time MAY choose to start with smaller initial reordering thresholds to minimize recovery latency. </del> <ins> Implementations can detect spurious retransmissions and increase the reordering threshold in packets or time to reduce future spurious retransmissions and loss events.  Implementations with adaptive time thresholds MAY choose to start with smaller initial reordering thresholds to minimize recovery latency. </ins> 5.1.1.

Discussion:
by clarifying that one may start with a smaller time threshold, not a smaller packet threshold.
The doc says: "Implementations that detect spurious retransmissions and increase the reordering threshold in packets or time MAY choose to start with smaller initial reordering thresholds to minimize recovery latency." For the packet based threshold does that this say that a smaller initial value than 3 packets could be used? Is that really sensible? And for a time based threshold I don't really understand what this means because the threshold is anyway calculated dynamically based on the RTT, so there is no real initial value. I guess there was a time when the threshold was a fixed value and this sentence is maybe a left-over?
Given the current guidance to never use packet thresholds below 3, I think this text should be changed to be clear that you can start with a smaller fraction of RTT and it only applies to time threshold.
I think the fix will be editorial, but once a PR is out we'll know for sure.
If it's only about time-based threshold, any advise should be moved in the respective subsection. However, I would also be okay to just remove this sentence/paragraph...
Change:
computers. There are also use cases where PSKs are shared between more than two <del> entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova): </del> <ins> entities.  Some examples below (as noted by Akhmetzyanova et al. AASS19): </ins> Group chats.  In this use-case, group participants may be provisioned an external PSK out-of-band for establishing

Discussion:
NIT: Might be better to say: Just drops some redundant words.
I think some things that should be more positive: -- For both PSK authentication and PSK key exchange without (EC)DHE the bad security properties such as lack of identity protection and lack of forward secrecy can be overcome by using one-time PSKs. External PSKs with short lifetimes are quite common in many real deployments. I think this should be mentioned. -- I think quantum resistance should be mentioned earlier in the document. Quantum resistance is a security property, not use a use case. Some things that should be more negative: -- In the list in 4.1 you can add "4. Any group member can blame any other group member." Other comments: -- "then PSK-only key establishment modes are secure against both active and passive attack." I think this you need to describe the exact attacks you have in mind rather than use the work "secure". My view would be that acceptable security in 2021 includes both identity protection and forward secrecy. But more on a system level, then necessarily by TLS itself. -- "DH" I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher suites in obsolete versions of TLS. -- "As discussed in Section 6, there are use cases where it is desirable for multiple clients or multiple servers to share a PSK." "However, as discussed in Section 6, there are application scenarios that may rely on sharing the same PSK among multiple nodes." Unless you have any real deployments to share, I think this should be reformulated. These are Gedankenexperiments used to illustrate the attack, not real-world applications. I would reformulate and remove "desirable", group PSKs should be very much discouraged. Suggestion: "As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] describes scenarios where multiple clients or multiple servers share a PSK."
Change:
A flow showing the use of a Retry packet is shown in fig-retry. <del> 8.1.2. </del> <ins> 8.1.3. </ins> A server MAY provide clients with an address validation token during one connection that can be used on a subsequent connection.  Address

Discussion:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG
Change:
target host to the server during the TLS handshake.  If the server is identified by a DNS name, clients MUST send the Server Name Indication (SNI) RFC6066 TLS extension unless an alternative <del> mechanism for indicate the target host is used. </del> <ins> mechanism to indicate the target host is used. </ins> QUIC connections are established as described in QUIC-TRANSPORT. During connection establishment, HTTP/3 support is indicated by

Discussion:
Follow-up to URL
Or "for indicating" :man_shrugging: not sure what the most appropriate one is.
Change:
however important to remember that endpoints sharing the same group PSK can always impersonate each other. <ins> Considerations for external PSK usage extend beynond proper identification.  When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that contributes to key diversity between sessions.  As a result, when an external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. </ins> 9. This document makes no IANA requests.

Discussion:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.
Change:
Packet numbers are limited to this range because they need to be representable in whole in the Largest Acknowledged field of an ACK frame (frame-ack).  When present in a long or short header however, <del> packet numbers are reduced and encoded in 1 to 4 bytes, see packet- </del> <ins> packet numbers are reduced and encoded in 1 to 4 bytes (see packet- </ins> encoding). <del> Version Negotiation (packet-version) and Retry packet-retry packets </del> <ins> Version Negotiation (packet-version) and Retry (packet-retry) packets </ins> do not include a packet number. Packet numbers are divided into 3 spaces in QUIC: <del> Initial space: All Initial packets packet-initial are in this </del> <ins> Initial space: All Initial packets (packet-initial) are in this </ins> space. <del> Handshake space: All Handshake packets packet-handshake are in </del> <ins> Handshake space: All Handshake packets (packet-handshake) are in </ins> this space. Application data space: All 0-RTT and 1-RTT encrypted packets <del> packet-protected are in this space. </del> <ins> (packet-protected) are in this space. </ins> As described in QUIC-TLS, each packet type uses different protection keys.

Discussion:
The deleted parenthetical is not accurate, and is unnecessary: 0-RTT and 1-RTT with various key phases share a PN space without sharing keys. I prefer the MUST NOT in coalescing, but if there are objections I can revert it.
Thanks Martin.
All good apart from the MUST NOT. I'm with Martin -- everything else looks fine.
Change:
The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved <del> value in I-D.ietf-core-block. </del> <ins> value in RFC7959. </ins> In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the

Discussion:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.
Change:
The DTLSCiphertext structure omits the superfluous version number field <del> DTLS adds an explicit epoch and sequence number in the record </del> <ins> DTLS adds an explicit epoch and sequence numbers in the record </ins> header.  This sequence number allows the recipient to correctly verify the DTLS MAC.

Discussion:
I do understand that the text is consistent with the one in , but I think that it could benefit from some rework.
Change:
Definitions of new HTTP Upgrade Tokens can state that their associated request's data stream uses the Capsule Protocol.  If they do so, that means that the contents of the associated request's data <del> stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> stream uses the following format: </ins> An intermediary can identify the use of the capsule protocol either through the presence of the Capsule-Protocol header field (hdr) or by

Discussion:
Inspired by Martin Duke's suggestion to reference integer encoding more directly, this change just sticks it all in one place and makes it clear that there is no expectation to minimally-encode varints. Styled on similar references to QUIC made in URL
Change:
7.1.9. <ins> groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that can be accepted from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  For a multi-streaming transport, this limits the number of allowed streams. 7.1.10. </ins> The following generic Connection Properties are read-only, i.e. they cannot be changed by an application. <del> 7.1.9.1. </del> <ins> 7.1.10.1. </ins> zeroRttMsgMaxLen

Discussion:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.
Change:
If issued, the resulting access token would contain sufficient access to be used at both referenced resources. <ins> 9.2. Additional methods of discovering the appropriate grant endpoint for a given application are outside the scope of this specification. This limitation is intentional, as many applications rely on static configuration between the client instance and AS, as is common in OAuth 2.0.  However, the dynamic nature of GNAP makes it a prime candidate for other extensions defining methods for discovery of the appropriate AS grant endpoint at runtime.  Advanced use cases could define contextual methods for contextually providing this endpoint to the client instance securely.  Furthermore, GNAP's design intentionally requires the client instance to only know the grant endpoint and not additional parameters, since other functions and values can be disclosed and negotiated during the grant process. </ins> 10. The editors would like to thank the feedback of the following

Discussion:
Built To edit notification comments on pull requests, go to your ._
The discovery process defined in GNAP details how to get information about the AS once you know the grant endpoint and can talk directly to it. We do not cover how to get the grant endpoint, except in the one case of it being provided by the RS at runtime in a response. The core document should at least discuss this gap as intentional, and an extension specification (or several) could be written to fill this gap in different circumstances.
Change:
8. <del> There are IANA considerations to be filled in. </del> <ins> 8.1. It is requested that IANA assign a new tag from the "Concise Binary Object Represetion (CBOR) Tags" registry.  It is requested that the tag be assigned in the 0 to 23 value range. Tag Value: TBD1 Data Item: CBOR map Semantics: COSE security message. </ins> 9.

Discussion:
Fix install instructions in the README for kramdown-xml2rfc Update COSE spec for tagging discussion Update Issues document for closed and newly opened discussion issues.
Carsten has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures. Should this be done?
a) CBOR Tag - either general or specific to each type b) Required Identifier c) Use the same techniques as JOSE There was no support for option C. There was support for Option B There was some support for Option A, but only if it was optional. Mike Jones suggested that we should use the header parameter 'typ', I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the JWS document. At this point I will keep the field as mandatory and outside of the headers field. I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text.
Closed in Pull request
Change:
4.5.6. <del> The literal field line without name reference representation encodes a field name and a field value as string literals. </del> <ins> The literal field line with literal name representation encodes a field name and a field value as string literals. </ins> This representation begins with the '001' three-bit pattern.  The fourth bit is the 'N' bit as described in literal-name-reference.

Discussion:
This saves bytes (that's the most important reason). This uses something positive rather than something negative to define the instruction. Yes, it means that there are two "Literal"s in the name of an instruction. But now it says what is inside rather than what isn't.
NAME I can't solve all the problems :) I think that in HPACK "literal" was reserved for the value more than the name. Maybe this only highlights that...
I understand. This commit at least solves some of them, thank you for the improvement!
Beauty is in the eye of the beholder. What am I to do with all the "wonr" variable names?
Without Name Reference might be better replaced as "With Literal Name" (Damn my enter key...)
Also consider changing on line 1640, but GitHub won't let me comment that far from a change.I think this is an improvement. It has always bothered me that "literal field line" is used in sitations when only part of the field line is literal, and this change does not address that. An alternative would be: insert with literal name => insert literal field line (or literal entry) literal field line with name reference => field line with name reference and literal value literal field line with literal name => literal field lineSeems like a sensible change.
Change:
generated by the origin.  This value can be a unique per-request nonce, or represent some state such as properties of the client session or current time window.  Valid lengths for this field are <del> either 0 or 32 bytes.  Challenges with redemption_context values </del> <ins> either 0 or 32 bytes.  The field is prefixed with a single octet indicating the length.  Challenges with redemption_context values </ins> of invalid lengths MUST be ignored. "origin_name" is an optional string containing the name of the <del> origin.  This allows a token to be scoped to a specific origin. If empty, any non-origin specific token can be redeemed. </del> <ins> origin, which allows a token to be scoped to a specific origin. The string is prefixed with a 2-octet integer indicating the length, in network byte order.  If empty, any non-origin-specific token can be redeemed. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:

Discussion:
For anyone unfamiliar with TLS struct notation, spell out the length fields in the text.