jiebi/CodeConvo huggingface dataset:
Change:
immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded. <del> Any changes to the BUNDLE policy take effect immediately, i.e. any future tracks added to the PeerConnection will have their bundle-only state marked accordingly. </del> <ins> The BUNDLE and RTCP-multiplexing policies MUST NOT be changed after the construction of the PeerConnection. </ins> This call may result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity

Discussion:
Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed
Change:
version in Version Negotiation packets, then the old version is no longer accepted. <del> 12. </del> <ins> 13. </ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. <del> 13. </del> <ins> 14. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for

Discussion:
(hopefully)
okay, next try. Moved some text to applicability and rewrote stuff in manageability... please review again...
Discussion in closed PR
Change:
3.8. <del> The round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC-TRANSPORT. </del> <ins> The round-trip time (RTT) of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC- TRANSPORT. </ins> 3.8.1.

Discussion:
Refers to quicwg. This also addresses /extremely limited/ ECN visibility (limited for sure, but we don't need to say "extremely"). Fixed multiple definitions of RTT Refered to metrics, etc for encrypted traffic wrt network-layer measurement via a REF.
Thanks for the suggestions from Ian and Mirjay, they were of course incorporated.
Change:
tcp <del> IESG (iesg@ietf.org) </del> <ins> The IESG (iesg@ietf.org) </ins> <del> The Web Push WG (webpush@ietf.org) </del> <ins> The IETF Chair (chair@ietf.org) </ins> HTTP Web Push

Discussion:
This attempts to address all of the issues identified during AD review: URL I have reviewed this document in preparation for IETF last call. It is almost ready to go. I have a few comments below. Once these are resolved and a rev published, I will request publication. = Shepherd write-up = RFC 2818 is in the downref registry already. That is the only explanation necessary for the downref. = Section 5.3 = I'm assuming the application scenarios listed in the table are illustrative since they do not cover every possible application. It would be good to note that. = Section 5.4 = "Delivery receipts for the deleted message SHOULD be suppressed." Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. = Section 8 = I think the first paragraph should include a normative recommendation to follow the guidance in RFC 7525 for use of TLS. = Section 8.2 = I think it would be useful to acknowledge in this section that while correlation using push URIs can be limited in the various ways described, correlation based on other information exposed by user agents may still be possible. = Section 9.3 = The Contact should be IETF Chair (per RFC 6335).
Change:
PATH_ABANDON frames contain the following fields: <del> Path Identifier: An identifier of the path, which is formatted as shown in fig-path-identifier-format. Identifier Type: Identifier Type field is set to indicate the type of path identifier. Type 0: Refer to the connection identifier issued by the sender of the control frame.  Note that this is the connection identifier used by the peer when sending packets on the to-be- closed path.  This method SHOULD be used by default. Type 1: Refer to the connection identifier issued by the receiver of the control frame.  Note that this is the connection identifier used by the sender when sending packets on the to-be-closed path. Type 2: Refer to the path over which the control frame is sent or received. Path Identifier Content: A variable-length integer specifying the path identifier.  If Identifier Type is 2, the Path Identifier Content MUST be empty. </del> <ins> The identifier of the path that should be abandoned. </ins> A variable-length integer that indicates the reason for abandoning this path.

Discussion:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
From PR by NAME
Looks good to me
Change:
Version control systems are a critical component of software engineering and are also quite useful for document editing. <del> Git [4] is a distributed version control system that can operate </del> <ins> Git [2] is a distributed version control system that can operate </ins> without a central service.  Each instance of a repository contains a number of revisions.  Each revision stores the complete state of a set of files.  Users are able to create new revisions in their copy

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
Abstract <del> This document specifies the "Connection ID" concept for the Datagram Transport Layer Security (DTLS) protocol, version 1.2 and version 1.3. </del> <ins> This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol.  I-D.ietf-tls-dtls13 specifies the Connection ID for DTLS version 1.3. </ins> A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.
Change:
helper, and so on. The leader responds to well-formed requests to "[leader]/upload" with <del> HTTP status code 200 OK and an empty body.  Malformed requests are handled as described in errors.  Clients SHOULD NOT upload the same measurement value in more than one report if the leader responds with HTTP status code 200 OK and an empty body. </del> <ins> HTTP status code 200 OK.  Malformed requests are handled as described in errors.  Clients SHOULD NOT upload the same measurement value in more than one report if the leader responds with HTTP status code 200 OK. </ins> If the leader does not recognize the task ID, then it MUST abort with error "unrecognizedTask".

Discussion:
Section 4.2.2: "Clients SHOULD NOT upload the same measurement value in more than one report if the leader responds with status 200 and an empty body.”" Is a non-empty body understood to signal an error condition based on some other context? What if the client got status 200 from the leader but a non-empty body? Should the client retry as this text suggests? I don't know enough about HTTP semantics to know for sure, but it seems like specifying an empty body here is unnecessary. It seems fine to specify that the leader should send an empty body for 200, but maybe be less strict on the consumption side and drop the empty body requirement?
Change:
the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS <del> server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before.  It is left to the EAP- TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket which was issued is still valid.  However, the EAP-TLS server MAY choose to require a full handshake.  As in a full handshake, sending a NewSessionTicket during resumption is optional.  As described in Appendix C.4 of RFC8446, reuse of a ticket allows passive observers to correlate different connections.  EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of RFC8446. </del> <ins> server accepts it, then the resumed session has been deemed to be authenticated, and securely tied to the associated with the prior authentication or resumption.  It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before. It is left to the EAP-TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket which was issued is still valid.  However, the EAP-TLS server MAY choose to require a full handshake.  In the case a full handshake is required, the negotiation proceeds as if the session was a new authentication, and resumption had never been requested.  The requirements of Sections section_auth and ticket then apply in their entirety.  As described in Appendix C.4 of RFC8446, reuse of a ticket allows passive observers to correlate different connections.  EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of RFC8446. </ins> It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake.  This

Discussion:
The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge
Change:
RFC3629. The application-specific variant of CONNECTION_CLOSE (type 0x1d) can <del> only be sent using 0-RTT or 1-RTT packets (QUIC-TLS, Section 4). </del> <ins> only be sent using 0-RTT or 1-RTT packets; see Section 4 of QUIC-TLS. </ins> When an application wishes to abandon a connection during the handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error code of APPLICATION_ERROR in an Initial or a Handshake

Discussion:
The longer the draft sits in my edit buffer, the more opportunities I have to see this sort of thing.
Change:
zero, which corresponds to the "null" compression method in prior versions of TLS.  If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST generate a fatal <del> "illegal_parameter" alert.  Note that TLS 1.3 servers may receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS. </del> <ins> "illegal_parameter" alert.  Note that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS. </ins> Clients MAY request extended functionality from servers by sending

Discussion:
When talking about handling downlevel clients, the spec variously says a server "MAY" receive such messages, or "may" receive such messages. Since this is discussing a possibility (not a permitted behavior), the normative language isn't correct; lower-case versions of the RFC2119 terms have the potential to confuse readers. Suggest changing all of these to "might" to denote a possible occurrence server implementers will need to handle.
Yes, this looks like an improvement.
LGTM
Change:
updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from <del> the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret </del> <ins> the resolution node * Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For

Discussion:
For now, I've only touched the sections until the "Cryptographic Objects" section, which seems to be outdated anyway. Once those are updated at some point, I'm happy to help moving from hashing to KDF-derivation there as well.
Thanks Konrad ! : )
Change:
The payload is structured as follows: We sometimes refer to this message as the _report_. The message <del> contains the "task" fields of the previous request.  It also includes the time (in seconds since the beginning of UNIX time) at which the </del> <ins> contains the "task_id" of the previous request.  It also includes the time (in seconds since the beginning of UNIX time) at which the </ins> report was generated.  The rest of the message consists of the encrypted input shares, each of which has the following structure:

Discussion:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information.

So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.
Change:
For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in RFC4733, Section 2.5.1.2. <del> If the application attempts to transmit DTMF when using a media format that does not have a corresponding telephone- event format, this MUST result in an error. </del> <ins> If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats. </ins> For any specified "ptime" value, configure the available media formats to use the specified packet size when sending.

Discussion:
NAME PTAL
On page 69, at "If the application attempt to transmit DTMF when using a media format that does not have a corresponding telephone-event format, this MUST result in an error". This sentence is out-of-place. The section is about applying a remote description. If the document needs to retain the sentence, it belongs off in some "processing media" section. In particular, the current placement of text is confusing about what and when an error could be returned, and it could be misread to say that an error should be returned to the setRemoteDescription call.
I agree
Agreed; I don't really feel like we need to create a new "Sending DTMF" section, so my recommendation would be to adjust the text to something like For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats.
LGTM
Change:
application request, and therefore the default candidate pool size MUST be zero. <del> Lastly, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic- sdp-bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: </del> <ins> The application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: </ins> The application will BUNDLE all media streams of the same type together.  That is, if there are multiple audio and multiple video

Discussion:
Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed