jiebi/CodeConvo huggingface dataset:
Code change:
SignatureAlgorithm registries to also refer to this document. [SHALL update/has updated] the TLS HashAlgorithm Registry to list <del> values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </del> <ins> values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-6 and 9-223 as "Reserved". </ins> Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers

Related discussion:
text: 4492bis includes some values we were marking as reserved and that's wrong. We also have 224-255 that we might also mark as reserved. Effectively, this closes these two registries.
NAME PTAL
NAME -- This looks good. I have a quick comment on: I presume this will or won't happen as the result of conversations in the WG? Also, I'll note -- for the (only) -- that only 224-253 are necessary to mark as reserved (or, really, since they were previously okay for private use, I think the term to use is "deprecated"), since 254 and 255 are in the TLS 1.3 "reserved for private use" range of 0xfe00-0xffff
I'm planning to forward the PR to the WG after I heard from you. I'll add in "deprecated" for those other values before sending it along.
Code change:
references.  Like all search criteria, on a resource lookup it can match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any <del> group resource that endpoint is contained in. </del> <ins> group resource that endpoint is contained in.  Queries for resource link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

Related discussion:
text: This decides the open question of how to match the in a query in favor of client simplicity. Closes: URL NAME NAME would that change be OK with you and solve the issue?
I know what an absolute form is, where do I find out what a path absolute form is
path-absolute is an ABNF in RFC3986, described as "begins with a '/' but not '//'".
I agree with the addition. This means that one can match against an absolute registration target as well.
Jim in :
It's a trade-off between not being a surprise to the RD implementation (with b, it needs to compare values that it has not seen in that form) versus not being a surprise to the lookup client (with a, it queries for something it does not see in that form in the query result). I think that the latter is preferable. Here are some more questions on the document. The registration text in section 5.3 says that the interface is idempotent, however it is not clear to me just how idempotent this is supposed to be. It is obvious that the goal is to make sure that a different resource is not created, however I am not clear what is supposed to happen with some of the parameters such as the 'lt' parameter. One way to implement this is to just make it a POST to the previously existing resource which would inherit old attributes on the endpoint. The other way is to say we are going to create a new resource, it just has the same address. It is not clear which, if any, of these two methods is to be used. Never mind I found the answer to this one. Need to think if I want clearer language. When doing an endpoint lookup, I assume that the 'lt' parameter would be the same as the one registered at creation. Is there/should there be a parameter which is a TTL value? How are href comparisons done. a) compare against what was registered b) Resolve what was registered and the href in the current context and compare c) something I did not think of compare on group for remote endpoint. Should this do the remote lookup or can it just be ignored for attribute comparison Value of lt = should it be the set parameter or the time left - how would time left be represented outherwise - should it be represented. Inferred context based on source IP when an update is done.
Code change:
references.  Like all search criteria, on a resource lookup it can match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any <del> group resource that endpoint is contained in. </del> <ins> group resource that endpoint is contained in.  Queries for resource link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

Related discussion:
text: If no con is provided, is that supposed to be checked again to see if it is "right"? Only if we did the infer to begin with? I don't understand the presence of the content-format for the empty message posted for simple registration. This seems to be odd if the content is empty. 8 Is there supposed to be a way for simple registration to return an error message? As written this is not necessarily done. Specifically, the response to the post can be executed before the query to /.well-known/core is done and the registration is attempted.
Code change:
To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier <del> for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. </del> <ins> for which authorization is being requested. </ins> The identifier that the account is authorized to represent:

Related discussion:
text: Previously there was some notion of being able to hint to the server whether you wanted to reuse authorizations. This was removed from the spec but the pre-authorization flow still made a reference to it. This commit removes that obsolete reference. Thanks to NAME for pointing out the error. Resolves URL
Hi in the section on pre-authz there is this sentence: To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. the part "and how the server should behave with respect to existing authorizations for this identifier" probably is obsoleted
Hi NAME I submitted URL to fix this. Thanks for spotting & reporting :-)
Code change:
4.4.2. <del> Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length. The server ID immediately follows. </del> <ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. </ins> The load balancer decrypts the nonce and the server ID using the following three pass algorithm:

Related discussion:
text: I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits
Code change:
connection error of type H3_DATAGRAM_ERROR. HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's <del> send side is open.  Once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so related state can be released.  State MAY be kept for a short time to account for reordering.  Once the state is released, the received associated datagrams MUST be silently dropped. </del> <ins> send side is open.  If a datagram is received after the corresponding stream's receive side is closed, the received datagrams MUST be silently dropped. </ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop

Related discussion:
text: The draft currently states: However in PR , NAME points out that this "state" is not well defined. I agree, we should fix it. Thinking about this more, I don't think we need the concept of related state. We can instead just say that received datagrams MUST be silently dropped if the stream receive side is closed.
I agree with removing the concept of state is better. I don't want to be overly nitty and the proposed sentence is better but there also nothing like "the stream receive side", as there can be multiple streams (open and closed), that's why I proposed Or if we don't want state, then it would be:
That's not quite right: there cannot be multiple streams, as datagrams are strongly associated with a client-initiated bidirectional stream. I'd phrase the paragraph as: open. If a datagram is received after the receive side of the corresponding stream is closed, the received datagrams MUST be silently dropped.
That works. Thanks!
This answer is necessary because QUIC doesn't guarantee ordering, but is this necessarily true indefinitely? But can I regard a datagram that arrives an hour after the stream closes as an error?
If you keep track of QUIC packet numbers, you can see that the peer closed the stream before it sent the datagram which means they violated a MUST. You're welcome to error if you detect that, but I don't think we should mandate this level of tracking.
I'm not sure that that is a good strategy given how some deployments manage their packet numbers. I'm talking about maybe running a really long timer.
That introduces a way for an attacker to cause connection closure by delaying a specific packet. What problem are you trying to solve?
Good point. I thought that we did similar in a few places in QUIC. As you say, it's possible to enforce, but tricky. The concern I'd have is that this effectively forbids enforcement, but maybe that's OK.
Code change:
signature key depending on the sender's "sender_type": "member": The signature key contained in the Credential at the <del> leaf with the sender's "LeafNodeRef" </del> <ins> index indicated by "leaf_index" in the ratchet tree. </ins> "external": The signature key contained in the Credential at the <del> index indicated by the "sender_index" in the "external_senders" group context extension (see Section external-senders-extension). In this case, the "content_type" of the message MUST NOT be "commit", since only members of the group or new joiners can send Commit messages. </del> <ins> index indicated by "sender_index" in the "external_senders" group context extension (see Section external-senders-extension).  In this case, the "content_type" of the message MUST NOT be "commit", since only members of the group or new joiners can send Commit messages. </ins> "new_member": The signature key depends on the "content_type":

Related discussion:
text: This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.
Code change:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 7. </del> <ins> 8. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" defined in this

Related discussion:
text: and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.
Code change:
If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del> <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Related discussion:
text: Fixed
also tagging NAME (who might be unhappy with 'default' which matches Chrome behaviour but not Firefox behaviour (it generates a uuid)
ping NAME NAME
NAME NAME PTAL - Barring any objections this one ought to get merged.
Folks, I think this one is pretty uncontroversial - planning to land this next week if there are no objections.
Take this simplified SDP offer from a remote endpoint (in parts taken from : A single audio and video stream. No a=mid (there is quite some text taking care of that) but no a=msid line either. URL shows a live example. Both Chrome (without unified-plan) and Firefox will fire the ontrack event (or legacy onaddstream) with a single mediastream containing an audio and video track. This has been like that since... 2012-ish? Unified plan support in Chrome changes this behaviour: URL ontrack is fired with an empty set of media streams. onaddstream is not fired. This is quite a change in behaviour. And unexpected, I didn't expect any issues for this trivial case of a single audio/video track. As NAME webrtc-pc assumes/requires a=msid to be present and . In particular this says which means firing with no streams is technically correct. JSEP seems to assume it is present as well, but has this text about a=msid in Note the "If present". What if it is not present? The closest I could find in terms of guidance was this from the and its section about handling a=msid is supposed to be present in initial offer so we are talking about dealing with non-webrtc entities send an offer. Given that there is plenty of support for entities that do not support a=mid (an RFC published in 2010) in JSEP do we need backward compability for the case of a single audio/video track each but no msid? Interop between browsers is probably not affected, due to Chrome still interpreting and sending a=ssrc:123 msid:...
note that a proper webrtc client will include "no streams" as (maybe with a track) which allows differentiating between "no streams because I do not use any" and "msid???"
Code change:
If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del> <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Related discussion:
text: Thanks NAME for another
aside: the interesting case you have trouble distinguishing between is "no msid because I haven't started sending a track yet" and "no msid because I don't support msid". It's one case where we still have trouble if RTP packets arrive ahead of signalling. But - yes, I think we are better off sticking with the 2012 behavior, default stream and all. We can handle the case above by changing the stream associations of the receiver if a new SDP (with msid) arrives after the RTP packets.
there used to be a a=msid-semantic line that would allow determining whether a party wants its offer to be treated assuming msid support. Browsers still send it :-)
How are non-signaled tracks supposed to be handled anyway? There's JSEP language about creating a track for it, but what about webrtc-pc? (If a track exists in the forest, and nobody is around to surface it to JavaScript, does it still exist?) "Run the following steps for each media description in description" means no ontrack will fire until we do have something signaled. If the track (and/or stream) only exists in some inaccessible way they're almost conceptual until the signaling does arrive. And when it does arrive, we know whether or not MediaStreams were signaled. So we should know what to do, same things as if we didn't receive early RTP packets? Does the distinction matter? I love that we can tell the difference between "no streams because I do not use any" and "no msid signaled" whether or not "a=msid:-" was present. I had not thought about that! Unless I'm confused about something, I suggest: If is present, do what Chrome does: don't create any stream. If the line is completely missing, do what Firefox (or Chrome Plan B) does: create a MediaStream with a random id. Does that work for people?
By the way I thought this was a webrtc-pc issue when I replied above, so I was thinking about what to do in JavaScript rather than talking about any JSEP change.
I suppose we need some JSEP language to handle the lack of any a=msid but i agree with what you propose above. We do have have a=msid:- and we need to handle that in webrtc-pc too.
Code change:
If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del> <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Related discussion:
text: Will file an issue there.
All webrtc-pc says is "let msids be a list of the MSIDs that the media description indicates transceiver.[[Receiver]].[[ReceiverTrack]] is to be associated with. Otherwise, let msids be an empty list" And says "The special value "-" indicates "no MediaStream"." So that already takes care of the case correctly, I claim. I agree. We need to solve what the media description (JSEP) says about this. Right now : "If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored." I think it needs to say what happens when it is not present. Something like: "If no a=msid is present, then in place of "msid-id", create a single "id" unique to this end-point, if one hasn't already been created for this connection."
"if one hasn't already been created for this connection"; so future tracks will share the same stream? There is always at most a single "default stream"?
NAME says he observed this is how Firefox and Chrome work. URL
See URL
LGTMreason I asked is that chrome generates a MediaStream with id "default" -- see URL while Firefox does not. (I do not see any reason to change the legacy behaviour of chrome even though it seems a bit odd that the RNG always emits the right bytes for "default")
Code change:
(CID) to the DTLS record layer.  The presence of the CID is negotiated via a DTLS extension. <ins> Adding a CID to the ciphertext record format presents an opportunity to make other changes to the record format.  In keeping with the best practices established by TLS 1.3, the type of the record is encrypted, and a mechanism provided for adding padding to obfuscate the plaintext length. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: As suggested by Éric Vyncke, mention that the new ciphertext record format provides ContentType encryption and per-record padding in both abstract and introduction.
URL Update from Éric re: Section 6
About "-- Section 3 --, DTLS / zero-length CID" "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello." The "zero-length CID" therefore is mainly used for the very common cases, where only the clients are required to send such a CID, but not the server. Maybe adding a hint to RFC5246 7.4.1.4 will help?
About "-- Section 6 --" Yes, that's still very complex: First, processing the record seems to be easier (less restricted), than use a changed source address for sending data back. Using a changed source address for sending data back to, is not generally solved. There are some special case, e.g., if the data sent back is very small, there is no risk (at least, none has explained one). There may also be some upper-layer mechanisms, which helps out (e.g. for coap). And there is a idea of a general solution , but that will require more time. Because of the required time, the idea was to release this spec without RRC and postpone that general work (see also issue ).
also in the abstract ? Some initial attempt at this in
LGTM Éric Vyncke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.