jiebi/CodeConvo huggingface dataset:
Change:
RFC3264, Section 6.1.  In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in I-D.ietf-mmusic- <del> sdp-bundle-negotiation, Section 10.2.  If any indicated media format is not supported, this MUST result in an error. </del> <ins> sdp-bundle-negotiation, Section 10.2. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload <del> type, as described in RFC4588, Sections 8.6 and 8.7.  If any referenced primary payload types are not present, this MUST result in an error. </del> <ins> type, as described in RFC4588, Sections 8.6 and 8.7. </ins> If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media.

Discussion:
The local description can never be wrong, because it is constructed by the browser. I also explicitly added text to make clear that the mux state for any m= line cannot change.
LGTM
Section 5.8 describes the behavior of an implementation processing its own unmodified SDP. It contains significant error language that should have been removed when SDP munging was removed. In particular, please remove all of the following: • "If an error is returned, the session MUST be restored to the state it was in before performing these steps." • "If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error." • "If any indicated RTP header extension is not supported, this MUST result in an error." • "If any indicated media format is not supported, this MUST result in an error." • "If any referenced primary payload types are not present, this MUST result in an error." The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only.
I think Adam is right about this, but I wonder if this actually belongs elsewhere, so further study needed.
This is already duplicated. This seems to be a prohibition that is stricter than RFC 5761, and if we remove it here we have removed it generally, unless I have missed somewhere else we say it. This is not appropriate for remote descriptions. We say this in 5.9. >The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only. Yeah, I think Adam is right about this and it's probably the result of some section refactor
Made some progress on it. Editor discussion on the mux piece. Once an m= line has mux or non-mux negotiated, that's immutable.
LG with nits
Change:
12. <del> QUIC, as defined in RFC9000, has a single congestion controller and </del> <ins> QUIC, as defined in QUIC, has a single congestion controller and </ins> recovery handler.  This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, that have the same DiffServ

Discussion:
as well
I didn't expect any other normative reference than RFC 9000, 9001 in this document. Why are other references needed to be listed in the normative reference? The reference list also have duplicate entries (i.e. same ref named differently) this need to be fixed as well.
I added this to PR - changed TLS1.3 and RFC6335 to informative, so only RFC8999, RFC9000, and RFC9001 should bee normative now.
I noticed that there are references to QUIC I-Ds. Applicability even references both -34 and RFC9000 :smile:
Change:
11.2. <del> The Trust Token API TRUST has been devised as a generic API for providing Privacy Pass functionality in the browser setting.  The API is intended to be implemented directly into browsers so that server's can directly trigger the Privacy Pass workflow. </del> <ins> The Trust Token API TrustTokenAPI has been devised as a generic API for providing Privacy Pass functionality in the browser setting.  The API is intended to be implemented directly into browsers so that server's can directly trigger the Privacy Pass workflow. </ins> 11.3.

Discussion:
Add allowances in protocol doc for redemption metadata Provide privacy analysis of including metadata to architecture doc Update privacy parametrizations cc NAME NAME NAME (I don't know everyone's github usernames, so feel free to add others who will be interested in reviewing).
LGTM
The main protocol document assumes that VOPRF is the main instantiation of PrivacyPass. It also has support for ciphersuites that augment this particular instantiation. It's not clear how we'd "extend" this protocol to support other features, such as public verifiability or the k-bits of metadata. These seem to be separate "modes" or "configurations" of PrivacyPass. (I don't think it makes sense to try and cast the metadata bit variant as a different ciphersuite for the main instantiation.) I propose we add some text describing different configurations. A configuration is an instantiation of the PrivacyPass API with certain properties. A configuration may (should?) also be extensible where applicable, e.g., in the ServerUpdate message or IssuanceRequest/Response messages. Interoperability across configurations would be unsupported, as they have would like have fundamentally different properties. Some initial configurations that come to mind are: PrivacyPass with no metadata bits (VOPRF construction) PrivacyPass with k metadata bits (Google's design) PrivacyPass with public verifiability (blind signatures?) cc NAME
Added some more information about supporting additional metadata in . As discussed elsewhere, I think the way to go here is for extensions to just specify new ciphersuites with associated privacy/security guarantees.
A number of applications expect the Servers to be able to add a small amount of metadata to the Privacy Pass protocol. We should add a discussion on how metadata should be added to tokens, and then describe the subsequent impact that this would have on the client's expected privacy budget. Generally speaking, adding a bit of metadata to tokens is likely to have a very similar impact to introducing an extra Issuer, and so this is something that will have to be covered in the general parametrization guidelines in the architecture document. Specific mechanisms for adding metadata to tokens are yet to be proposed, but may appear as alternative instantiations in the protocol document, or be specified separately as individual extensions.
LGTM. We’ll need to work through the extensibility support for the metadata bit variant next.
Change:
This document specifically focuses on streaming applications and defines streaming as follows: <del> Streaming is the transmission of continuous media from a server to </del> <ins> Streaming is the continuous transmission of media from a server to </ins> a client and its simultaneous consumption by the client. <del> Here, "continuous media" refers to media and associated streams </del> <ins> Here, "media" refers to any type of media and associated streams </ins> such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous," as it is not considered streaming if one downloads a media file and plays it after the download is

Discussion:
NAME and NAME - note that John's last comment hasn't been addressed in this PR yet.
Added a single comment for the subsequent sentence where you made a change.
NAME and NAME - Most of John's comments are nits and easy to resolve, but there are two that need thought. First, this comment So, let's think about this. We're looking at two, related statements, I'm wondering if it is correct to say Streaming is continuous transmission of media from a server to a client and its simultaneous consumption by the client. I'll make that change, and see if anyone objects. Second, this comment (followed by some excellent guesses about recourse) I read this text as saying that your streaming service is less complex if you have an intermediary that is modifying manifests during peak hours, than if you add that functionality to media servers that are already complex, especially if intermediaries are making a few well-understood changes to the manifests that only need to work for media players downstream on a given path, while a media server would have to maintain multiple versions of the manifests that that, in total, cover every possible modification that any intermediary would have done, and then figure out how to send each media player the appropriate version of the manifest for that media player. If that's what other people think, we can say that. If it's not what other people think, we need to talk.
The first one works for me ("Streaming is a continuous transmission of media"). For the second, yes, that was my intent. It is possible to deliver different manifests to different clients. Doing so based on some kind of aggregated estimate of the path load (possibly including peak hours/time of day, etc.) can do roughly the same job of reducing network load that was previously done with on-path edits to unencrypted manifests, but it adds a lot of complexity to the media service, which was previously instead taken on by (some of) the networks with a problem.
lgtm
Change:
request and response headers and identify the media content being streamed. <del> "End-to-end" media encryption became much more widespread in the years since RFC7258 was issued, which identified pervasive monitoring </del> <ins> "End-to-end" media encryption has become much more widespread in the years since the IETF issued "Pervasive Monitoring Is an Attack" RFC7258 as a Best Current Practice, describing pervasive monitoring </ins> as a much greater threat than previously appreciated.  After the Snowden disclosures, many content providers made the decision to use HTTPS protection - HTTP over TLS - for most or all content being delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". <ins> Unfortunately, as noted in RFC7258, there is no way to prevent pervasive monitoring by an "attacker", while allowing monitoring by a more benign entity who "only" wants to use DPI to examine HTTP requests and responses in order to provide a better user experience. If a modern encrypted transport protocol is used for end-to-end media encryption, intermediary streaming operators are unable to examine transport and application protocol behavior.  As described in hop-by- hop-encrypt, only an intermediary streaming operator who is explicitly authorized to examine packet payloads, rather than intercepting packets and examining them without authorization, can continue these practices. RFC7258 said that "The IETF will strive to produce specifications that mitigate pervasive monitoring attacks", so streaming operators should expect the IETF's direction toward preventing unauthorized monitoring of IETF protocols to continue for the forseeable future. </ins> 7. This document requires no actions from IANA.

Discussion:
I did add a few paragraphs of text, but don't expect it to be too controversial. Any thoughts?
Needs to be edited and possibly some text migrated.
Change:
The applicability statement may also contain information about supported cipher suites.  The procedure for selecting and verifying <del> cipher suite is still performed as specified by the protocol, but it may become simplified by this knowledge. </del> <ins> cipher suite is still performed as described in asym-msg1-form and wrong-selected, but it may become simplified by this knowledge. </ins> An example of an applicability statement is shown in appl-temp.

Discussion:
Addressing
NAME Please check if your comments are addressed.
Yes, especially in [1]. Thanks! [1] URL
-08 contained a definition of CREDx including an example when kid is used. -09 removed that example and replaces it with a RPK by value example. Now it seems like the most important use case is not well specified. This is the use case that leads to message2 being 45 bytes.
In addition the TOFU use case should likely also have a kid. Otherwise the UCCS has to be sent by value every time.
This is solved by just adding a 'kid' in the COSE_Key map
The document should say someting more about COSEKey. If IDCREDx = { 4 : keyidx } identifies a raw COSEKey, is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub?
SUITES_R is a name. The type needs to be defined and the table changed. This can be done in PR
The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included. This works and allows the Initiator to give the Responder information about the full list. This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong. i.e. the following are all valid I think we should simplify SUITESI by mandating that the last suite in the list is the selected. This makes SUITESI much easier to understand and lowers message size when an array is used. Giving the Responder info is not so important. CDDL
Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports.
Currently SUITESR : [ supported : 2 suite ] / suite We may keep that, or remove "supported" SUITESR : [ 2 suite ] / suite Alternatively, we may define SUITES_I : [ supported : 2* suite ] / suite Any preference?
They should be the same: or And then
This needs to be defined as a CDDL type. suites = [ 2* suite ] / suite See
Change:
indication that traffic is restricted, which can be used as a prompt to contact the API. <ins> The Captive Portal Signaling Protocol does not provide any means of indicating that the network prevents access to some destinations. The intent is to rely on the Captive Portal API and the web portal to which it points to communicate local network policies. </ins> The Captive Portal Enforcement function MAY send Captive Portal Signals when disallowed User Equipment attempts to send to the network.  These signals MUST be rate-limited to a configurable rate.

Discussion:
Point out that future Captive Portal Signalling Protocols will not enable non-binary blocking. Fixes Issue
There are networks that want to selectively block things. We aren't going to get consensus on whether that is good practice, but we do have consensus that we don't provide protocol mechanisms for communicating about selective blocking. Document that fact.
Closed in .
Change:
function is declared to have a result type of "ValueType", or (conversion applies) "NodesType". <del> Otherwise, it is occurring as an argument to a further function </del> <ins> Otherwise, it occurs as an argument in another function </ins> expression, and the following rules for function arguments apply to its declared result type.

Discussion:
These editorial changes from PR are needed in the base.
I confess I tend to write tedious text when precision is at stake. Hopefully, the second commit avoids the tedium.
Why was this merged so quickly?!
We merged this editorial change quickly so we could rebase the other substantive PRs on it and put us in a better position to compare their pro's and con's.
Looks good now! Should merge this quickly so we can rebase the others.
Change:
Abstract, introduction: removed "or disperse networks" <ins> Security policies: Clarify that with all security policies, clients must verify the authorization of the RD. Remove speculation about how in detail ACE scopes are obtained. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Discussion:
…om authorized RDs This makes the paragraph that described that for a particular case largely redundant. The lines about that special case that described special considerations for ACE anticipate a mechanism that is not finished yet, and were removed.
Change:
11. <del> [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] [[OPEN ISSUE: Add some text to rename the extended_master_secret entry in the extensions registry to extended_main_secret, after the above is resolved.]] </del> This document uses several registries that were originally created in <del> RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are below: </del> <ins> RFC4346 and updated in RFC8446 and RFC8447.  The changes between RFC8446 and RFC8447 this document are described in bis-changes.  IANA has updated these to reference this document. The registries and their allocation policies are below: </ins> TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required

Discussion:
To keep the text in 8446bis and to avoid having people to read 8446 (and address the OPEN issues) in the IANA Considerations section - from IANA: If you want to keep the old actions in the document, we’d like to see those actions preceded by an introduction or sub-section (or more than one sub-section; however it’s appropriate to structure it) that tells us what the new actions are for this document.
The diffs are informative here - I think there's only adding general_error to TLS Alerts and updating the references to RFC 8446bis vice RFC 8446.
Apologies for any confusion - already address via .
Change:
As above, mitigation of this threat is beyond the scope of this proposal. <del> 5. </del> <ins> 6. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

Discussion:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM
Change:
2. This section describes the information required to register the above <del> media types according to </del> <ins> media type according to </ins> 2.1.

Discussion:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via
Change:
application requirements: In the case of an unreliable data transfer, the transport layer <del> may implement a non-reliable transport layer (e.g.  UDP or DCCP </del> <ins> may provide a non-reliable transport service (e.g.  UDP or DCCP </ins> RFC4340 or a partially reliable transport protocol such as SCTP with partial reliability RFC3758).  Depending on the amount of redundancy and network conditions, there could be cases where it

Discussion:
Small changes, nothing urging, should be easy to merge if you are ok with it :-)
Change:
incentives for manufacturers to offer a firmware update mechanism as part of their IoT products. <del> 10. </del> <ins> 11. </ins> The discussion list for this document is located at the e-mail address suit@ietf.org [1].  Information on the group and information

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)
Change:
datagrams are often limited to less than 1500 bytes if IP fragmentation is not desired.  In order to compensate for this limitation, each DTLS handshake message may be fragmented over <del> several DTLS records, each of which is intended to fit in a single IP packet.  Each DTLS handshake message contains both a fragment offset and a fragment length.  Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented </del> <ins> several DTLS records, each of which is intended to fit in a single UDP datagram.  Each DTLS handshake message contains both a fragment offset and a fragment length.  Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented </ins> message. 3.4.

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
packets MUST define a mechanism that is robust against version downgrade attacks. <del> 21.10. </del> <ins> 21.11. </ins> Deployments should limit the ability of an attacker to target a new connection to a particular server instance.  This means that client-

Discussion:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)