jiebi/CodeConvo huggingface dataset:
Code change:
session-level attributes.  The process here is identical to that indicated in the Initial Offers section above. <ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the

Related discussion:
text: I cleaned up the language.
lgtm
Cullen wants LS groups because that is what legacy gear understands. Magnus wants to use MSID, which carries this.
Discussed in DC: will test out the LS group concept, Jonathan will send text to the list and we will discuss. Concerns are that there is a potential for mismatch between what is signaled in LS groups and what is signaled in MSID. We also need to work out what to do in the absence of LS groups.
bug 32 is prob dup of this
pinged Lennox
Given the discussion on CNAME, no one in the room at IETF90 objected to the idea that LS group was MTI.
Plan here is update draft to say that when creating the SDP, everything in PC has same CNAME, and the things in the same MediaStream get put in a LS (lipsync) group. This will mean legacy stuff that support LS will do the right thing, and legacy stuff that does not, will simply try and sync everything.
Cullen to ping Harald to get his LG regarding the comment above (ie. regarding its interaction with MSID)
Just to add some clarity here .... this is what I think we decided. All the RTP in a given PeerConection will use the same CNAME. For each stream, If a stream has more than one track, then the JSEP needs to create a lip sync group (see URL ) to put all the tracks in a given stream into the same lip sync group.
Yes. If no lipsync group from the remote side, everything is synchronized. If only some tracks in LS group, the rest are unsynchronized. (Basically, if you indicate you understand LS, we take what you give us, all synced)
MT, would you be willing to write some text here?
Who has the token here?
Just realized there could be a problem. Consider A, who does not want to sync its audio/video, and B, who wants its video to be synced. A offers a=group:LS with no mids. B has to reply with a subset of the proposed mids, by 5888 rules. Therefore B's a/v won't be synced. I don't see a good reason to require this, but 5888 is pretty clear.
Code change:
session-level attributes.  The process here is identical to that indicated in the Initial Offers section above. <ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the

Related discussion:
text: The identification-tags contained in this "a=group" line MUST be the same as those received in the offer, or a subset of them (zero identification-tags is a valid subset). When the identification-tags in the answer are a subset, the "group" value to be used in the session MUST be the one present in the answer.
There's an issue with LS when using bidirectional media sections. If media stream X (from A to B) uses media sections 1 and 2, and media stream Y (from B to A) uses media sections 2 and 3, what should be the lipsync groups? Are lipsync groups unidirectional or bidirectional?
see comment above. 5888 says bidi, but that is crazy talk.
Indeed. Crazy. What is our plan of attack here then? Can we ask MMUSIC to fix this? Either by un-screwing-up a=group (which seems unlikely), by making a new grouping semantic, or by telling us that there is a better option.
JSEP reserves the right to contradict existing standards where necessary. Generally, it seems like the need for symmetry in a=group is semantic-dependent, and so fixing it later in 5888 seems possible.
So you are suggesting that we define a=group:LS as declarative: it applies to the media that is sent by the peer that includes the grouping. I can live with that, though I suspect it will cause considerable heartburn. It certainly complicates the grouping model considerably.
yes, essentially. I don't see any way to reconcile LS with reality otherwise.
Changing the semantics of existing mechanisms by declaring that they are changed without actually changing them is a dangerous process. A simpler alternative is to drop media section reuse when LS groups are present: If a particular media section is a member of an LS group, or if a MediaStream requires its tracks to be part of an LS group, don't use it for a track in the opposite direction. The legacy case of one audio section, one video section that is used in both directions will then require that we somehow turn off LS group generation.
Code change:
multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <ins> Endpoints negotiate the use of one packet number space for all paths or separate packet number spaces per path during the connection handshake nego.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial when endpoints use zero-length connection ID for less overhead. </ins> 7.1. If the multipath option is negotiated to use one packet number space

Related discussion:
text: Not sure to understand why the last part of the sentence is an issue. The use of zero-length connection IDs is problematic anyway in setups with NATs, for example.
I agree that in many deployments you want at least one CID from the client to server. Multiple packet numbers as currently defined however requires CIDs in both direction; there is separate issue to discuss that. The next sentence also further explains that there might be other deployments though, e.g. in constraint networks, that might also benefit from saving the bits of the CID. This one sentence is of course only a very brief summary of the pros and cons of the different approach and more discussion is needed in the group. So I don't expect to have this part in the draft like this when we finally publish it as RFC. Is there anything in the issue that we need to address now? Or can we close this issue?
Thanks, Mirja. That's what I expected, but I do still think more elaboration is needed for this text to be useful. I would suggest to make this modification and leave the discussion of pros/cons to be adequately documented in Section 7: OLD: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path. While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header. While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility. More evaluation and implementation experience is needed to select one approach before final publication. Some discussion about pros and cons can be found here: URL URL NEW: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path. While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility. More evaluation and implementation experience is needed to select one approach before final publication.
Code change:
multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <ins> Endpoints negotiate the use of one packet number space for all paths or separate packet number spaces per path during the connection handshake nego.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial when endpoints use zero-length connection ID for less overhead. </ins> 7.1. If the multipath option is negotiated to use one packet number space

Related discussion:
text: Some discussion about pros and cons can be found here: URL URL
You are suggesting to strike out the sentences that try to summarize the differences, "While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connectionID. Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header." I think that's a good idea. The sentences are a short summary of the arguments presented in the powerpoint, which are not limited to "highly constrained networks". For example, the Chrome browser, by default, uses NULL CID. I may be placing words in the mouth of Google developers, but I believe their goal is to reduce the overhead of the QUIC header compared to TCP/TLS. This is related to a general quest for performance, not to network constraints.
Code change:
Update the "Reference" to also refer to this document. <del> Add the following notes: Experts are to verify that there is in fact a publicly available standard.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </del> See expert-pool for additional information about the designated expert pool.

Related discussion:
text: NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Code change:
invoking packet included in the ICMP packet and only forward the ICMP packet to the client whose scoping matches the invoking packet. <ins> Since there are known risks with some IPv6 extension headers (e.g., ROUTING-HDR), implementers need to follow the latest guidance regarding handling of IPv6 extension headers. </ins> 11. 11.1.

Related discussion:
text: From Vinny Parla on the :
I don't think we need to make normative changes to the protocol, but adding a note for implementers that they might want to treat extension headers differently that other IP protocols sounds like a good change. Some additional review comments from an internal review that I wanted to share with you. Section 4.6 has a minor issue as the IANA registry mixes IPv6 extension header with layer-4 headers. It should also specify the use of RFC 5952 for representing IPv6 addresses. However, this can be ignored for now. Section 4.7.1 unsure whether "IP Version" field is useful as it can be derived from "IP Address" length/notation, also not critical but perhaps this would reduce unnecessary information. There is also a minimum 68-byte MTU for IPv4 ;-) - not sure that is important, but wanted to share. The recursive DNS server info (found in RA and DHCP), is not present. Was this an intentional decision or perhaps something that was not considered for some reason? There is no discussion of link-local addresses / ULA (I would expect both end of the 'tunnel' to have link-local addresses), or link-local multicast (e.g., ff02::1). Or perhaps the IP proxy send an IPv6 RA ? or should be prevented from sending one ? Should IP proxy reply to ff02::2 (all link-local routers), ... -Vinny
Code change:
where a flight is very large and the receiver is forced to elide acknowledgements for records which have already been ACKed.  As noted above, the receipt of any record responding to a given flight MUST be <del> taken as an implicit acknowledgement for the entire flight. </del> <ins> taken as an implicit acknowledgement for the entire flight to which it is responding. </ins> 7.3.

Related discussion:
text: Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS.
Code change:
where a flight is very large and the receiver is forced to elide acknowledgements for records which have already been ACKed.  As noted above, the receipt of any record responding to a given flight MUST be <del> taken as an implicit acknowledgement for the entire flight. </del> <ins> taken as an implicit acknowledgement for the entire flight to which it is responding. </ins> 7.3.

Related discussion:
text: The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL
Code change:
Imported PSKs do not collide with future protocol versions and KDFs. <del> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </del> <ins> There are no known related outputs or security issues caused from the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below, as noted in rollout.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.

Related discussion:
text: I don't love a couple of the ways I phrased things here, so feel free to offer suggestions to improve it! modulo test vectors. (NAME it'll likely take some time to get those vectors. Do you think we should hold this document until that's done?)
This looks good modulo the open issue about incremental deployment. I don't think we need to hold the document up in order to get test vectors. Benjamin Kaduk has entered the following ballot position for draft-ietf-tls-external-psk-importer-06: Yes 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Sorry about the large volume of comments; this document is actually in pretty good shape, there are just a bunch of details that can be subtle to get exactly right. I specifically call out the note in Section 4.1 about which HKDF-Expand-Label is to be used, since that would affect the actual derived keys for DTLS 1.3 (and any hypothetical future TLS versions). Section 1 While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done. Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions. To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific key derivation function (KDF) and hash function for use in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS13]. [...] IIRC the main target use cases for this mechanism are for existing external PSKs (violating the "SHOULD" from the first quoted paragraph), as well as deployments that are simplified by only needing to provision a single PSK. Does it make sense to include such clarifying description here?
Code change:
Imported PSKs do not collide with future protocol versions and KDFs. <del> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </del> <ins> There are no known related outputs or security issues caused from the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below, as noted in rollout.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.

Related discussion:
text: (Similarly, is it accurate to say that "[a]pplications SHOULD provision separate PSKs [...], but the mechanism defined in this document provides a partial mitigation for use when that is not possible"? Also, we only use the word "interference" twice in this document (this is the first instance), so it might be worth a couple more words to clarify the nature of the potential interference. Section 3 non-imported keys for TLS versions prior to TLS 1.3. Non-imported and imported PSKs are distinct since their identities are different on the wire. See Section 6 for more details. (side note?) I think the precise story here is a little subtle -- for any given key, the imported and non-imported identities are distinct, but in principle one could construct a non-imported identity that overlaps with an imported identity for a different key (and we say as much at the end of Section 7). This is vanishingly rare to happen by chance, but makes the statement as written not quite categorically true. That said, the change to the binder key derivation (§ 4.2) seems to obviate any potential consequences to such a collision (though the connection attempt would presumably fail). Endpoints which import external keys MUST NOT use either the external keys or the derived keys for any other purpose. Moreover, each IIUC, this is "MUST NOT use the keys that are input to the import process for any purpose other than the importer, and MUST NOT use the derived keys for any purpose other than TLS PSKs". Is it worth spelling it out explicitly like that? external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from [RFC8446]. See Section 7 for more discussion. Does this requirement apply to the inputs to the importer process, the outputs, or both? Section 3.1 Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, target protocol, and target KDF. There is an "External Identity" that is contained within the EPSK itself; is the "External Identity" listed here distinct from that?