jiebi/CodeConvo huggingface dataset:
Code change:
6. When bundling, associating incoming RTP/RTCP with the proper "m=" <del> section is defined in RFC8843.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </del> <ins> section is defined in I-D.ietf-mmusic-rfc8843-bis.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </ins> Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m="

Related discussion:
text: In the rewritten offer the 3PCC controller will set the port value to zero (and include an SDP 'bundle-only' attribute) for each "m=" section within the BUNDLE group, excluding the offerer-tagged "m=" section. __ From: Roman Shpount Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg Cc: Justin Uberti ; Justin Uberti ; RTCWeb IETF Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e., a subsequent offer, will be used by a 3PCC controller to establish a new session and forwarded as an initial offer to another endpoint that is currently not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers. It cannot be assumed that a subsequent offer is a valid initial offer and that the endpoint that expects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer before it is used to establish a new session. To make the subsequent offer a valid initial offer, 3PCC will need to modify all the non-tagged m= lines to include the bundle-only attribute and set the m= line port to zero.
Code change:
6. When bundling, associating incoming RTP/RTCP with the proper "m=" <del> section is defined in RFC8843.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </del> <ins> section is defined in I-D.ietf-mmusic-rfc8843-bis.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </ins> Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m="

Related discussion:
text: _ Roman Shpount Christer Holmberg > wrote: Hi, What about something like this: OLD: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the procedures defined in Section 7.2.” NEW: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will therefore include a subsequent offer in the 200 OK responses. The offer will be received by a 3PCC controller (UAC) and then forwarded as an initial offer to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look different than a subsequent BUNDLE offer, it cannot be assumed that a UA that expects an initial offer will be able to properly process a subsequent offer.
Code change:
6. When bundling, associating incoming RTP/RTCP with the proper "m=" <del> section is defined in RFC8843.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </del> <ins> section is defined in I-D.ietf-mmusic-rfc8843-bis.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </ins> Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m="

Related discussion:
text: Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent (B2BUA), and when it receives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded to such UA.” Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL The PROBLEM is that we have two endpoints, where one sends a subsequent offer, and the other one expects an initial offer. What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway then maybe adding a=bundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (URL), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance. Roman Shpount
Not seeing any objections for a month then once -02 is submitted we will progress this towards our AD. spt
Code change:
If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (migrate-validate) to verify the peer's ownership of the address if <del> validation is not already underway. </del> <ins> validation is not already underway.  If the recipient has no unused connection IDs from the peer, it will not be able to send anything on the new path until the peer provides one; see migration-linkability. </ins> An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet.  This ensures

Related discussion:
text: Section 9.3 of Transport(URL) says: "If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (Section 8.2) to verify the peer's ownership of the address if validation is not already underway." In section 9.5(URL) "Similarly, an endpoint MUST NOT reuse a connection ID when sending to more than one destination address. Due to network changes outside the control of its peer, an endpoint might receive packets from a new source address with the same destination connection ID, in which case it MAY continue to use the current connection ID with the new remote address while still sending from the same local address." So as long as it's an unintentional change, everything is clear. But if the destination address changes and the incoming CID changes, but the sender(ie: server) doesn't have any more CIDs, it's not clear what should be done, as the two MUSTs seem to contradict one another. Or maybe they imply the server can't send anything?
Later in 9.5, there's also this text that is relevant, but I don't think it clarifies how to resolve the MUSTs. " An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts by its peer to migrate. To ensure that migration is possible and packets sent on different paths cannot be correlated, endpoints SHOULD provide new connection IDs before peers migrate; see Section 5.1.1. If a peer might have exhausted available connection IDs, a migrating endpoint could include a NEWCONNECTIONID frame in all packets sent on a new network path."
So the second quotation has that clarification (with emphasis): Isn't this all coherent?
Yes, that clarifies the issue when the CID does not change. But that does not clarify the case when the CID does change and the responder has no more CIDs.
Isn't that addressed by this: ?
So the answer is: 1) It can't send anything 2) It can send on the old path, but not the new one
It can probe the old path - but that is all it can do.
Why would it probe the old path that it's already validated?
I didn't say that it was useful, just possible :)
I don't see a pressing reason to do anything about this.
Code change:
If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (migrate-validate) to verify the peer's ownership of the address if <del> validation is not already underway. </del> <ins> validation is not already underway.  If the recipient has no unused connection IDs from the peer, it will not be able to send anything on the new path until the peer provides one; see migration-linkability. </ins> An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet.  This ensures

Related discussion:
text: That said, it's an unfortunate edge case, perhaps we could call it out explicitly, mentioning that this shouldn't arise if the other parts of the migration machinery are followed?
To be clear, I'm not looking for a fix as much as clarity on what is supposed to occur. I'll write a PR that I think will clarify it some and call out the edge case.
I'd argue this is really a MUST unless case, but people tend not to like those, so I tried to stick to the facts in my PR.
WFM
Code change:
RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </del> <ins> RFC5764 and TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </ins> registration RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and

Related discussion:
text: URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.
Code change:
Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext. <del> If the "proposals" vector contains any PreSharedKey proposals, derive the "psk_secret" as specified in pre-shared-keys, where the </del> <ins> Derive the "psk_secret" as specified in pre-shared-keys, where the </ins> order of PSKs in the derivation corresponds to the order of <del> PreSharedKey proposals in the "proposals" vector.  Otherwise, set "psk_secret" to 0. </del> <ins> PreSharedKey proposals in the "proposals" vector. </ins> Use the "init_secret" from the previous epoch, the "commit_secret" and the "psk_secret" as defined in the previous steps, and the new

Related discussion:
text: In , NAME noted that the concatenation approach used to combine multiple PSKs is not well validated. At the 2021-10-04 interim, we discussed moving from this approach to a "cascaded HKDF" approach, with the idea of doing the same thing here as the main key schedule. This PR implements that suggestion. One nice implication of the algorithm here is that when there are no PSKs, it produces the zero vector as a degenerate case. So you could implement it pretty cleanly:
The spec currently doesn't distinguish much between an external and a member commit w.r.t. how proposals by reference are handled. In theory, the server could keep track of proposals and send the external committer all proposals that were sent up until the time they want to commit externally. However, there are a few difficulties in committing proposals by reference in an external commit. Membership tags: The external committer doesn't have the ability to verify membership tags on proposals. This is probably not a show-stopper, as proposals still need to be signed by a group member, but if nothing else, this should be noted in the spec. Leaf positioning: The spec was changed such that the committer is added into the tree without an Add proposal being present. If there are other Add (and Remove) proposals present, it is unclear in what order they should be processed. Should the committer be added when the path is processed? Or should it still be processed as if it were an Add? There are probably other things that can go wrong when committing referenced proposals externally, but those are the first that come to mind. The simplest solution would be to simply ignore proposals by reference, although this would break the current principle that a commit must always include all valid proposals that were sent during the epoch. The consequence would be that Parties that sent proposals will have to re-send them if the epoch is ended by an external commit. It should be noted, that a Preconfigured sender will have no way to detect if their proposal was committed or not.
I'm not sure your worries here are very real: Membership tags: I don't think the membership tag issue matters, because the existing members will reject the proposal (and thus the commit) if the membership tag is invalid; at worst the joiner gets themselves wedged into a group by themselves.
Code change:
Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext. <del> If the "proposals" vector contains any PreSharedKey proposals, derive the "psk_secret" as specified in pre-shared-keys, where the </del> <ins> Derive the "psk_secret" as specified in pre-shared-keys, where the </ins> order of PSKs in the derivation corresponds to the order of <del> PreSharedKey proposals in the "proposals" vector.  Otherwise, set "psk_secret" to 0. </del> <ins> PreSharedKey proposals in the "proposals" vector. </ins> Use the "init_secret" from the previous epoch, the "commit_secret" and the "psk_secret" as defined in the previous steps, and the new

Related discussion:
text: And as you say, they're signed, and they keys can be tied back to the tree hash in the GroupInfo. Leaf positioning: We need to clear this up regardless of proposals-by-reference. It seems like basically having a synthetic Add at the beginning or end of the proposal list would work fine. Preconfigured proposer: This is a problem only when Commits are encrypted, so it's not a problem in the external commit case (since an external Commit cannot be encrypted). Nonetheless, the point that an external joiner can't fully verify a Proposal seems to argue pretty strongly for forbidding proposals by reference. I don't think this even violates the semantic of "include all valid proposals received in the epoch", since (1) that requirement is receiver oriented (it's not enough for the proposals to have been sent) and (2) the external joiner can't tell if the proposals or valid. Overall, I would lean slightly toward removing proposals by reference. And if we do that, it might even make sense to just define an ExternalCommit message that packages together the few things that are still allowed.
I'm not sure I understand how the receiver-orientation of the "all valid proposals must be included" rule matters to its application to this case. If we remove the requirement for external commits to include proposals by reference and don't soften that rule to exclude external commits, receivers will consider all external commits invalid in the presence of valid pending proposals by reference. In any case, I'm also in favor of keeping it simple and restrict the External Commit to a few, well defined components that do not include any proposals by reference.
Discussion on working call: "No proposals by reference" kind of follows from "all valid proposals", since the joiner can't necessarily determine that proposals are valid Maybe allow attempts? Might not get feedback to retry, though. Whole point of external commit is to allow async. Agreement to prohibit proposals by reference in external Commit
I believe there's a small mismatch between the text and the Key Schedule figure. The text says that if there are no PSK proposals, the should be a zero-length string, while the Key Schedule figure seems to indicate that it's a string of zeros of length .
Fixed in
One brief comment, otherwise looks good!
Code change:
and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A <del> UserInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.

Related discussion:
text: Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :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 .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Code change:
3.4.2.1. The process begins with a PACollectReq.  The leader collects a <del> sequence of reports that are all associated with the same PA task, helper URL, and helper HPKE config id.  Let "[helper]" denote "PACollectReq.helper_url".  The leader sends a POST request to "[helper]/aggregate" with the following message: </del> <ins> sequence of reports that are all associated with the same PA task. Let "[helper]" denote "PAParam.helper_url", where "PAParam" is the PA parameters structure associated "PAAggregateReq.task.id".  The leader sends a POST request to "[helper]/aggregate" with the following message: </ins> The structure contains the PA task, the helper's HPKE config id, an opaque _helper state_ string, and a sequence of _sub-requests_, each

Related discussion:
text: Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?
Code change:
be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans). <del> An example of a custom extension using a URI as "custom-problem- detail-entries" key is shown in fig-example-custom-with-uri. </del> <ins> fig-example-custom-with-uri shows an example (in CBOR diagnostic notation) of a custom extension using a (made-up) URI as "custom- problem-detail-entries" key. </ins> Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer <del> key; the same example but using a registered unsigned int as "custom- problem-detail-entries" key is shown in fig-example-custom-with-uint. </del> <ins> key; fig-example-custom-with-uint shows how the same example would look like using a (made-up) registered unsigned int as "custom- problem-detail-entries" key: </ins> In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom

Related discussion:
text: Start collecting changes from AD review
Comment by NAME : /example value 4711 not actually registered like this:/ ~~~ I don't get the sentence above - if this is to highlight that this is an example and that the value 4711 is not actually registered, I think this is redundant (and you could also add that in the Figure caption rather than in the example's text).
See : The danger that people are just blindly copying an example is just too high. So we would prefer to keep this redundant comment in. We could improve the wording of the comment.
Comment by NAME : Please explicitly state that the example (or examples if you add one in ) uses CBOR diagnostic notation.
Fixed in .
Closed by 7463ce1