jiebi/CodeConvo huggingface dataset:
Change:
11.3. <del> It is important to delete all security sensitive values S as soon as they, or another value derived from them, is used for encryption or decryption. </del> <ins> It is important to delete all security sensitive values as soon as they are _consumed_. A sensitive value S is said to be _consumed_ if </ins> <del> More precisely, the values application_[i]_[j]_key and application_[i]_[j]_nonce are said to be "consumed" if they were used either to: </del> <ins> S was used to encrypt or (successfully) decrypt a message, or if </ins> <del> encrypt or (successfully) decrypt a message or </del> <ins> a key, nonce, or secret derived from S has been consumed.  (This goes for values derived via Derive-Secret as well as HKDF-Expand- Label.) </ins> <del> if a key, nonce or secret derived from S has been consumed. (This goes both for values derived via Derive-Secret and HKDF-Expand- Label.) Here, S may be the init_secret, update_secret, epoch_secret, application_secret as well as any secret in the AS Tree or one of the ratchets. </del> <ins> Here, S may be the "init_secret", "update_secret", "epoch_secret", "application_secret" as well as any secret in the AS Tree or one of the ratchets. </ins> As soon as a group member consumes a value they MUST immediately delete (all representations of) that value.  This is crucial to

Discussion:
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
(for example, to keep the implementation complexity to a minimum) and has a secure channel, such as a local IPC, to interact with a lead Attester (see Composite Device, I-D.ietf-rats-architecture).  The <del> sub-Attester produces a UCCS with the required set of claims and </del> <ins> sub-Attester produces a UCCS with the required CWT Claims Set and </ins> sends the UCCS through the secure channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example,

Discussion:
(As per Ned Smith's message of November 8, 2022)
Claim Key as specified in RFC8392 are currently called lables in the CDDL in the Appendix. "Claim Key" by itself is only used in the definition of UCCS and never again. Should we decide on a consistent use of Claim Key or highlight that is a synonym to label before the CDDL in appendix?
Change:
addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with <del> dynamically generated Multicast DNS (mDNS) RFC6762 names. </del> <ins> dynamically generated Multicast DNS (mDNS) names. </ins> 1.

Discussion:
From the 'nits' link on top of the IETF submitted version. ** The abstract seems to contain references ([RFC6762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question.
Probably can just move the ref to the intro section.
URL
LGTM
Change:
1. <ins> This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard.  A glossary is proposed in sec:glossary. </ins> Guaranteeing both physical-layer robustness and efficient usage of the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how

Discussion:
Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?
In PR : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.
Change:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions". <ins> This section defines the extension point as well as four function extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are mandatory to implement. </ins> A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a result.

Discussion:
Add note that using the extension point mechanism doesn't imply the "function extensions" to be non-mandatory.
Change:
it can send.  The size SHOULD be derived from the result of performing path MTU discovery. <del> 4.2. </del> <ins> In the WebTransport model, all of the outgoing and incoming datagrams are placed into a size-bound queue (similar to a network interface card queue). Any WebTransport protocol SHALL provide the following operations on the session: Enqueues a datagram to be sent to the peer.  This can potentially result in the datagram being dropped if the queue is full. Dequeues an incoming datagram, if one is available. Returns the largest size of the datagram that a WebTransport session is expected to be able to send. 4.3. </ins> A unidirectional stream is a one-way reliable in-order stream of bytes where the initiator is the only endpoint that can send data.  A

Discussion:
Currently, in the W3C API draft, we cite the HTTP/3 draft and RFC 9000 directly. This does not work with WebTransport over HTTP/2, hence we need for the overview draft to provide a common set of operations that both H3 and H2 versions of the draft are expected to implement.
cc NAME NAME NAME NAME
How does this square with the set of features that we list in the overview draft -- right now it looks like we'll just have two lists. Do we want to do anything to relate them / break things down as being part of each feature? (Not saying that's strictly necessary, just curious if we'd thought about it)
Chair: discussed at 113, request for folks to review this PR
Thanks everyone for the comments! I've revised the PR; please take another look. By features, you mean the requirements in the section above that? Those are somewhat different in nature, I feel. The features are the list of things that I should be able to do with a WebTransport, whereas the requirements are on how it is supposed to work (e.g. you must use TLS, etc).
(no hats) overall this LGTM, my comments are minor
Change:
tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. <del> Some of the properties of the QUIC header used in network management are irrelevant to application-layer protocol operation and/or user privacy.  For example, packet number exposure (and echo, as proposed in this document), as well as connection establishment exposure for 1-RTT establishment, make no additional information about user traffic available to devices on path. At the other extreme, supporting current traffic classification methods that operate through the deep packet inspection (DPI) of application-layer headers are directly antithetical to QUIC's goal to provide confidentiality to its application-layer protocol(s); in these cases, alternatives must be found. </del> 7. This work is partially supported by the European Commission under

Discussion:
The last two paragraphs of the security considerations section were for a (much earlier, probably pre-WG) version of the document. Now that -manageability is basically a wire image users' guide, they don't belong. So let's cut them.
Change:
Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 <del> of RFC4303. The received record counter for an association MUST be initialized to zero when that association is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less </del> <ins> of RFC4303.  Because each epoch resets the sequence number space, a separate sliding window is needed for each epoch. The received record counter for an epoch MUST be initialized to zero when that epoch is first used.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received in that epoch during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number. Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less </ins> powerful one than whether the record was deprotected. Duplicates are rejected through the use of a sliding receive window.

Discussion:
It gets reset each time the epoch does. Don't talk about values as being scoped only per association.
Change:
in RFC6904, Section 4. For each supported RTCP feedback mechanism that is present in the <del> offer, an "a=rtcp-fb" mechanism, as specified in RFC4585, Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. </del> <ins> offer, an "a=rtcp-fb" line, as specified in RFC4585, Section 4.2. The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. </ins> If the RtpTransceiver has a sendrecv or sendonly direction:

Discussion:
Page 51, bullet starting "For each supported RTCP feedback...": replace "an 'a=rtcp-fb' mechanism" with "an 'a=rtcp-fb' line".
Section Initial Answers Text is For each supported RTCP feedback mechanism that is present in the offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. Fix trivial typo
Page 38, second-to-last bullet refers to "an 'a=rtcp-fb' mechanism" where it should say "an 'a=rtcp-fb' line".
Agreed
Change:
same type (typically "a=") can occur in any order, and their ordering is not meaningful. <del> For non-attribute (non-"a=") lines, their sequencing, syntax, and semantics, are checked, as mentioned above.  The following lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. </del> <ins> The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. </ins> The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to

Discussion:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)
Change:
Same as for TLS 1.3. <del> Same as for TLS 1.3. </del> <ins> Versions of TLS and DTLS before version 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in version 1.3.  A client which has a cached session ID set by a pre- DTLS 1.3 server SHOULD set this field to that value.  Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field). </ins> A DTLS 1.3-only client MUST set the legacy_cookie field to zero length.  If a DTLS 1.3 ClientHello is received with any other

Discussion:
It is not the same as TLS 1.3, as previously stated, because DTLS 1.3 does not support the compatibility mode.
It seems a natural consequence of not having compatibility mode, but is probably worth running by the list just to cover all bases.
Change:
Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del> <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.

Discussion:
LGTM!
JSEP on two occasions says "SDP media description" where it seems "SDP session description" or similar would be more appropriate. "media description" seem to reference m-lines rather than the full SDP in other documents (4566, 3264).
agree - see if that pull request fixes it
to my understanding it does fix it!
Change:
Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del> <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
[[ TODO: point to stable reference which describes the analysis of these goals ]] <del> 9. </del> <ins> 8. </ins> External PSK identities are typically static by design so that endpoints may use them to lookup keying material.  However, for some systems and use cases, this identity may become a persistent tracking identifier. <del> 10. </del> <ins> 9. </ins> This specification introduces a new registry for TLS KDF identifiers and defines the following target KDF values: <del> +-------------+-----+ | Description | Value | +-------------+-----+ | Reserved | 0x0000 | | | | | HKDF_SHA256 | 0x0001 | | | | | HKDF_SHA384 | 0x0002 | +-------------+-----+ </del> New target KDF values are allocated according to the following process:

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. <del> 6.8. </del> <ins> 6.6. </ins> To request that a certificate be revoked, the client sends a POST request to the ACME server's revoke-cert URI.  The body of the POST

Discussion:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).
Change:
used directly in conjunction with the record protocol. Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, <del> IKEv2 </del> <ins> IKEv2, OpenVPN </ins> Direct export: TLS, DTLS, MinimalT

Discussion:
I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1
Change:
3. <del> This document clarifies correct DNS server behaviour expectations and does not introduce new security considerations. </del> <ins> While not common, real life examples of servers that fail to set TC=1 when glue records are available exist and they do cause resolution failures. 3.1. The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour has also been seen with plain DNS responses as well.  The records have been truncated for display purposes.  Note that at the time of this writing, this configuration has been corrected and the response correctly sets the TC=1 flag. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. 3.2. A zone's sibling glue is glue in another zone that is required for proper resolving.  While the example below is obvious, real life examples can be more complex and not obvious. This situation is harder to detect if the sibling zones are nog hosted on the same nameservers. 3.3. When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones depending on this glue are not broken.  Technically, these NS records are no longer glue records, but authorative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </ins> 4. <ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. 5. </ins> There are no actions for IANA.

Discussion:
Clarify glue, slightly reorder.
Merging - as mentioned in email, I will also add a more typical case of sibling glue (that doesn't involve cross zone and circular dependency). PR forthcoming ...
Change:
packet protection keys for Initial packets. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCID Len field to indicate the length. </del> <ins> its choosing and sets the SCID Length field to indicate the length. </ins> The first flight of 0-RTT packets use the same Destination Connection ID and Source Connection ID values as the client's first Initial

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.