jiebi/CodeConvo huggingface dataset:
Change:
for the context in which the LeafNode is being validated (as defined in ratchet-tree-node-contents). <del> Verify that the following fields in the KeyPackage are unique among the members of the group (including any other members added in the same Commit): </del> <ins> Verify that the following fields in the LeafNode are unique among the members of the group (including any other members added in the same Commit): </ins> "public_key" "credential.signature_key" <ins> Verify that the extensions in the leaf node are supported.  The ID for each extension in the "extensions" field MUST be listed in the field "capabilities.extensions" of the LeafNode. </ins> 8.2. In order to provide forward secrecy and post-compromise security,

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
4.1. <del> A code in the 7.01-7.31 range indicates a Signaling message.  Values </del> <ins> A code in the 7.00-7.31 range indicates a Signaling message.  Values </ins> in this range are assigned by the "CoAP Signaling Codes" sub-registry (see message-codes). For each message, there is a sender and a peer receiving the message. <del> Payloads in Signaling messages are diagnostic payloads (see </del> <ins> Payloads in Signaling messages are diagnostic payloads as defined in </ins> Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling message option.

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
sources.  For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc.  For remote time sources, the provided time <del> must be guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </del> <ins> must be both authenticated and guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </ins> The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not

Discussion:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.
Change:
Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <ins> Connection Properties describe the default behavior for all Messages on a Connection.  If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message.  For example, if "Reliable Data Transfer (Connection)" is set to "Require" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "false" for a particular Message will allow this Message to be unreliably delivered.  Note that changing the Reliable Data Transfer property on Messages is only possible for Connections that were established with the Selection Property "Configure Per-Message Reliability" enabled. </ins> The following Message Properties are supported: 7.5.1.

Discussion:
I inserted the text that I quoted in this issue, with a minor tweak.
List discussion: Kyle: NAME
I agree with the conclusion of NAME above - in which case we should leave things as they are. Other views?
I agree that if the application does nothing then communication should be reliable. But I understand Kyle's comment as asking about the relationship to the selection property Reliable Data Transfer (Connection). If you for example set that to Avoid and the TAPS system selects SCTP as the protocol, then if you do not set Reliable Data Transfer (Message) on a message I assume it will be sent as an unreliable message. So in that sense the reliability of a message defaults to whatever is set for the connection, unless it is overridden by setting Reliable Data Transfer (Message). And the default for Reliable Data Transfer (Connection) is Require so what NAME writes still holds but it is a different thing.
So if we agree upon Reliable Data Transfer (Connection), then it would seem less confusing for Reliable Data Transfer (Message) - to use the same logic. Does an apps writer need to know the data will be sent as an unreliable message? (I'm not sure I like "avoid reliable data transfer" as a meaningful concatenation of keywords BTW:-).
Let's see what needs to be done. Suggestion: the only textual change would be to add the following, at the beginning of Section 7.5, just before "The following Message Properties are supported": "Connection Properties describe the default behavior for all Messages on a Connection. If a Message Property contradicts a Connection Property, it overrides the Connection Property for the specific Message. For example, if "Reliable Data Transfer (Connection)" is set to "Avoid" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "Prefer" for a particular Message will ensure that this Message is reliably delivered. If the underlying protocol can not support this per-Message behavior, this Message Property choice will yield an error."
Thanks! No more comments now :)
Change:
<del> Using EAP-TLS with TLS 1.3 </del> <ins> Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) </ins> draft-ietf-emu-eap-tls13-latest Abstract

Discussion:
I see that "EAP-TLS 1.3" is used more an more in the discussions to refer to this the combination of EAP-TLS and TLS 1.3. The term is used in the document but not in the title and abstract
Hi John, Please run this title change by the list.
Looking at this it seems that this change is simpler than I originally thought. This looks OK to merge
Change:
A server not using this functionality SHOULD make the six bits appear to be random. <ins> 3.4. The first octet has the following fields: CR: Config Rotation bits. CID Len: Length Self-Description (if applicable).  Encodes the length of the Connection ID following the First Octet. </ins> 4. In QUIC-LB, load balancers do not generate individual connection IDs

Discussion:
Erik Fuller points out via email: He's right. We should just call it a configuration ID and be clearer on what's what.
Change:
JSEP applications typically inform the browser to begin ICE gathering via the information supplied to setLocalDescription, as this is where <del> the app specifies the number of media streams to gather candidates for.  However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application MAY ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup.  When setLocalDescription is eventually called, and the browser goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the </del> <ins> the app specifies the number of media streams for which to gather candidates.  However, to accelerate cases where the browser knows the number of media streams to use ahead of time, the application MAY ask the browser to gather a pool of potential ICE candidates to help ensure rapid media setup.  When setLocalDescription is eventually called, and the browser goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the </ins> application immediately via the ICE candidate callback.  If the pool becomes depleted, either because a larger-than-expected number of media streams is used, or because the pool has not had enough time to

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
7.3.3. <del> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jwsd" in string form. The signer creates a JWS RFC7515 object as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:

Discussion:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc
Change:
by replacing the old account key with the public key carried in the "jwk" header parameter of the "newKey" JWS object. <ins> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body. If the update was not successful, then the server responds with an error status code and a problem document describing the error. </ins> 6.5. Once a client has created an account with an ACME server, it is

Discussion:
I'm not sure if this is the correct place for issues with the actual server, but https://acme-URL is returning me an error message of When accessed from several machines.
No, this isn't the right place. Contact LetsEncrypt directly. This is for discussing the IETF protocol.
https://ietf-wg-URL does not detail what status code should be returned. I assume it should be a 202, in line with Registration update, but it needs specifying IMO.
Change:
A client that migrates to a new address SHOULD use a preferred address from the same address family for the server. <ins> The connection ID provided in the preferred_address transport parameter is not specific to the addresses that are provided.  This connection ID is provided to ensure that the client has a connection ID available for migration, but the client MAY use this connection ID on any path. </ins> 9.7. Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label

Discussion:
This just writes down what NAME suggested in .
Two things need to be clarified around SPA: The CID is not path-specific; it's there to ensure that the client has a second CID before the handshake completes. If the client opts not to migrate, the client can use that CID on the The IP addresses in the SPA are only for use in the transition post-handshake; the client should not cache the IP addresses for any other use.
(Just filling in the text here) on the original address from the server, which is the existing connection, not-migrated. +1 to the second point
If the server is telling the client to migrate to a SPA, should this be changed to "the client MUST select one of the two server's preferred addresses ..."? If the text remains a SHOULD, and the client stays on the old server address, what can the server do if it is only willing to continue with the new connection on the SPA? The server could close the initial connection using the old server address but there isn't a transport error code (e.g. MIGRATION_ERROR) that would explicitly tell the client why the connection is being closed.
The "SHOULD" is intentional. A server cannot rely on clients moving.
Then perhaps a cautionary note such as "If the client opts not to migrate to a preferred address, the server may [lower case] decide to close the connection (e.g. SERVER_BUSY)".
If the server isn't willing at all to handle connections on its published IP address, then (naively) it shouldn't accept connections on that IP address and should publish the other one instead. The scenario this targets is that it's somehow better for the client to use a different address, but that other address can't necessarily be known in advance.
Migrating to a unicast address avoids having to perform connection-based routing through a load balancer.
Change:
Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are <del> identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </del> <ins> identical.  This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

Discussion:
Page 41 contains a statement reading "This promotes readability," which might be read by some as promoting machine parsing rather than troubleshooting. I propose replacing "readability" with "troubleshooting."
Full text: Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical. This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. I'm not sure that 'troubleshooting' is the exact word we're looking for here, but I think we can come up with something.
Change:
Verify that the "hpke_init_key" value is different from the corresponding field in the KeyPackage being replaced. <del> Verify that the set of identities attested by the credential is acceptable to the application for the participant being updated. </del> Replace the sender's leaf KeyPackage with the one contained in the Update proposal

Discussion:
This PR moves the remark that there has to be validation of the attested identities upon a credential update to the KeyPackage validation subsection. It also changes the responsibility for the check to be that of the AS rather than that of the application. Note, that the boundaries are somewhat arbitrary at this point, since the application running on the local device may well implement parts of the AS. The reason for this change is to ensure any validation checks that pertain to authentication are part of the AS.
NAME Please make any required changes to the architecture document as well. Since I think that's where the AS is defined.
Right now it says in the Update proposal section: "Verify that the set of identities attested by the credential is acceptable to the application for the participant being updated." Firstly, I think this is a matter of authentication and thus the AS' job and secondly, it's a validation step that should probably go into the section.
Discussion on virtual interim: Depends on what the boundary of the AS is: Checking credential is valid Also checking (credential -> credential) transitions Moving this check to KP validation section would make it clearer NAME to make a PR
Fixed by
Change:
should provide guidance on what extensions are sensitive and suggest suitable substitutes.]] <del> To encrypt ClientHelloInner, the client first needs to generate the HPKE encryption context.  It computes the encapsulated key, context, and HRR key (see hrr) as: </del> <ins> To encrypt EncodedClientHelloInner, the client first needs to generate the HPKE encryption context.  It computes the encapsulated key, context, HRR key (see hrr), and payload as: </ins> Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the AEAD/KDF used with "context" <del> are those which match client's chosen preference from "ECHConfig.cipher_suites".  The encrypted ClientHelloInner is computed as: </del> <ins> are those which match the client's chosen preference from "ECHConfig.cipher_suites". </ins> <del> The payload of the "encrypted_client_hello" extension in the </del> <ins> The value of the "encrypted_client_hello" extension in the </ins> ClientHelloOuter is a "ClientECH" with the following values: "cipher_suite", the client's chosen cipher suite;

Discussion:
Along the way, I've made two additional tweaks: Renamed outerextension to outerextensions, now that it contains multiple extensions. One of the diagrams even already referred to "outerextensions" because I didn't realize it was called "outerextension".Clarified in compression process and ClientHelloInner construction rules that the to-be-compressed extensions must be consecutive. Hopefully that helps with .
NAME FYI. I'm hoping this will help clarify why the ordering thing isn't actually a big deal.
I've updated the PR to include text to disambiguate the serialization. It's ambiguous whether the encoding includes the 4-byte (12-byte in DTLS) header from the Handshake structure or is just the body, from the ClientHello structure. I've picked the smaller one. This also saves having to answer, in DTLS, what happens when the inner sequence number is wrong.
There are two ClientHelloInners, the actual one used in the handshake, and the encoded one with outerextensions substituted in. Both are described as ClientHelloInner, but this makes it slightly ambiguous which goes into, say, the handshake transcript. (It's late now, so I'll leave this as an issue without a PR. If we don't end up resolving this separately, I'll probably fix this as part of . If we decide to implicitly copy over legacysession_id, the encryption payload becomes less and less defensibly an actual ClientHelloInner.)
In my own implementation, I've been referring to the plaintext payload as CompressedClientHelloInner. Which is terrible, but unambiguous.
Works for me. I was thinking EncodedClientHelloInner because it's shorter and still works even if you choose not to compress anything. (A no-op encoding is still an encoding.)
+1 to EncodedClientHelloInner, given that compression is optional. NAME if you have time, could you whip up a PR?
Change:
services. Implementation of a low-latency live video service can be achieved <del> with the use of low-latency extensions of HLS (called LL-HLS) I- D.draft-pantos-hls-rfc8216bis and DASH (called LL-DASH) LL-DASH. These extensions use the Common Media Application Format (CMAF) standard MPEG-CMAF that allows the media to be packaged into and transmitted in units smaller than segments, which are called chunks in CMAF language.  This way, the latency can be decoupled from the duration of the media segments.  Without a CMAF-like packaging, lower latencies can only be achieved by using very short segment durations. However, using shorter segments means using more frequent intra-coded frames and that is detrimental to video encoding quality.  CMAF allows us to still use longer segments (improving encoding quality) without penalizing latency. </del> <ins> with the use of "HTTP Live Streaming (HLS)" RFC8216 by using its low- latency extension (called LL-HLS) I-D.draft-pantos-hls-rfc8216bis or with "Dynamic Adaptive Streaming over HTTP (DASH)" MPEG-DASH by using its low-latency extension (called LL-DASH) LL-DASH.  These extensions use the Common Media Application Format (CMAF) standard MPEG-CMAF that allows the media to be packaged into and transmitted in units smaller than segments, which are called chunks in CMAF language. This way, the latency can be decoupled from the duration of the media segments.  Without a CMAF-like packaging, lower latencies can only be achieved by using very short segment durations.  However, using shorter segments means using more frequent intra-coded frames and that is detrimental to video encoding quality.  CMAF allows us to still use longer segments (improving encoding quality) without penalizing latency. </ins> While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
In this tree, we can see all of the above rules in play: <del> The resolution of node Z is the list [Z, C] </del> <ins> The resolution of node X is the list [X, B] </ins> <del> The resolution of leaf 1 is the empty list [] </del> <ins> The resolution of leaf 2 or leaf 6 is the empty list [] </ins> <del> The resolution of top node is the list [A, Z, C] </del> <ins> The resolution of top node is the list [X, B, Y, H] </ins> 5.1.2.

Discussion:
The current resolution example tree can't be created by the protocol. If C were not blank, then D would not populate Z in its filtered direct path. (Note that this implies that there are never unmerged leaves at the first level of the tree.) This PR expands the example tree so that it can have unmerged leaves while still having a blank top node. This makes the example a little more complicated (you have to follow the recursion down two levels), but it doesn't seem too bad.
cc NAME
Good catch! It's kind of subtle in this case.
NAME - I think I have this patched up, would appreciate a quick re-review.
I walked through the example tree on a whiteboard with different colored markers and it looks correct to me.