jiebi/CodeConvo huggingface dataset:
Change:
4.2.2. <del> The stopped method returns "true" if the transceiver has been </del> <ins> The stopped property indicates whether the transceiver has been </ins> stopped, either by a call to stopTransceiver or by applying an answer <del> that rejects the associated m= section, and "false" otherwise. </del> <ins> that rejects the associated m= section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.

Discussion:
stopped The stopped method returns "true" if the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section, and "false" otherwise. [BA] This should be rewritten as follows:
Agree, there is precedent for this regarding the canTrickleIceCandidates property in URL We should make these consistent (note use of 'property' vs 'attribute')
Change:
Root zone S <ins> SERVFAIL </ins> SOA field names Secondary server Secure Entry Point (SEP)

Discussion:
I have added your text (approximately) and merged the pull request.
During the discussion that led to RFC 7719, there was a request to split out error names in their own terms to make them easier to find in the document. Now with the index in place, this seems like a good idea.
Oooh, yes, I think that this would be great. [Sorry for the non-substantive / bikeshed comment]
Entered in the doc as URL
I think this is ok, but I'd like a tiny edit before the list starts: "The names as of this writing are described below, but the official list is in the IANA registry." Or something like this. I just don't want to suggest we're arguing with the authoritative registry.
Change:
Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence.  Some common examples include the user of a mobile phone or FIDO <del> authenticator.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </del> <ins> authenticator. </ins> Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and

Discussion:
purpose statement into beginning of Security Considerations. I moved the statement to the beginning of section 12, but maybe some wanted it moved to the beginning of 12.1.
** Section 12.1.1 An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted"
Section 12.1.1 Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted" I think the statement is closer to "A foundational security assumption of a RATS architecture it that a Relying Party is able to establish the basis for trusting the Attester functions, or Attester users.
Remove word "assumption", as this is an input, and we are talking about the output. move this sentence to the beginning of that section. "The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester."
Change:
and results in a nodelist consisting of a single node is replaced by the value of the node and then: <del> comparison using one of the operators "==" or "!=" produce a "true" comparison result if and only if the comparison is between: </del> <ins> comparison using one of the operators "==" or "!=" yields true if and only if the comparison is between: </ins> primitive values which satisfy the comparison, or structured values compared using "!=". comparisons using one of the operators "<", "<=", ">", or ">=" <del> produce a "true" comparison result if and only if the comparison is between numeric values which satisfy the comparison. </del> <ins> yield true if and only if the comparison is between numeric values which satisfy the comparison. </ins> Note that comparisons between structured values, even if the values <del> are equal, produce a "false" comparison result. </del> <ins> are equal, yield false. Data types are not implicitly converted in comparisons.  So "13 == '13'" yields false. A regular-expression test yields true if and only if the value on the left-hand side of "=~" is a string value and it matches the regular expression on the right-hand side according to the semantics of I- D.draft-bormann-jsonpath-iregexp. </ins> The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp.

Discussion:
Fixes URL
Let's continue in URL
Currently the syntax section of the "Filter Selector" section describes some semantics. These descriptions should be folded into the semantics section.
I'm not sure we are done with this yet. See comments.The reordering looks good to me.
Change:
exactly match the media type and protocol values in the corresponding m= section in the associated offer. <ins> If any of the preceding checks failed, processing MUST stop and an error MUST be returned. </ins> 5.8. The following steps are performed at the media engine level to apply

Discussion:
This will happen when applying either an offer or an answer, for consistency. Also, any "semantics verification" failure will now result in an error, which was assumed but not explicitly stated. Fixes issue .
This is a good start, but you'll also want to update 4.1.1, 5.3.1 to reflect this (new) policy. Note though that this will end up being inconsistent with the handling of max-bundle as it is described in 4.1.1, although I still think this is the right approach.
Updated 4.1.1. I thought I already made the needed change to 5.3.1, what else needs to be changed?
I may be overlooking something, but I don't think this behavior is documented anywhere. I think the choices, in order of harshness, are: Silently fails, and you don't get RTCP negotiationneeded fires, and the m= section is port-zeroed in the next offer setRemoteDescription throws an error I'd lean towards the middle option, but that assumes that applications listen to negotiationneeded.
I lean toward the last option, as a violation of an invariant set by the offerer.
Agree that this should be documented somewhere.
+1 on the throw an error option
The general policy that we discussed here in Seattle was that any spec violation should lead to a setRD exception, not a zero port. For the rtcp-mux-only doc, we probably should have some language that makes rtcp-mux in the answer a MUST.
Resolved by
Change:
N NODATA <ins> NOERROR NOTIMP </ins> NSEC NSEC3 <ins> NXDOMAIN </ins> Naming system Negative caching Negative response

Discussion:
I have added your text (approximately) and merged the pull request.
During the discussion that led to RFC 7719, there was a request to split out error names in their own terms to make them easier to find in the document. Now with the index in place, this seems like a good idea.
Oooh, yes, I think that this would be great. [Sorry for the non-substantive / bikeshed comment]
Entered in the doc as URL
I think this is ok, but I'd like a tiny edit before the list starts: "The names as of this writing are described below, but the official list is in the IANA registry." Or something like this. I just don't want to suggest we're arguing with the authoritative registry.
Change:
Some networks may exhibit higher degrees of packet reordering, causing a sender to detect spurious losses.  Additionally, packet reordering could be more common with QUIC than TCP, because network <del> elements that could observe and reorder out-of-order TCP packets cannot do that for QUIC, because packet numbers are encrypted. Algorithms that increase the reordering threshold after spuriously detecting losses, such as RACK RACK, have proven to be useful in TCP and are expected to be at least as useful in QUIC. </del> <ins> elements that could observe and reorder TCP packets cannot do that for QUIC, because QUIC packet numbers are encrypted.  Algorithms that increase the reordering threshold after spuriously detecting losses, such as RACK RACK, have proven to be useful in TCP and are expected to be at least as useful in QUIC. </ins> 6.1.2.

Discussion:
This PR is also a good spot to comment on my accidental commit() to master. I can make any changes to that in this PR.
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
Some suggestions only.One nit, but LGTM.
Change:
frame is the offset of the next byte that would be sent. The first byte in the stream has an offset of 0.  The largest offset <del> delivered on a stream - the sum of the offset and data length - MUST be less than 2^62. </del> <ins> delivered on a stream - the sum of the offset and data length - cannot exceed 2^62-1, as it is not possible to provide flow control credit for that data.  Receipt of a frame that exceeds this limit will be treated as a connection error of type FLOW_CONTROL_ERROR. </ins> 19.9.

Discussion:
The text here had a MUST prohibiting data+offset from exceeding 2^62-1. But that is redundant with flow control, which can't express a limit greater than this anyway. So just point to FLOWCONTROLERROR.
Sec 19.8 says: The first byte in the stream has an offset of 0. The largest offset delivered on a stream - the sum of the offset and data length - MUST be less than 2^62. It certainly possible to express a STREAM frame that violates this rule. What action should we take?
I don't know if we ever wrote this down, but I think that we might say if you catch a peer violating the spec, then you can send an error of any type you like. But for this case, PROTOCOL_VIOLATION is entirely appropriate (as with many others of this sort).
Not just offset, but offset + content size of stream frame, otherwise there is no fixed limit on stream sizes, which is unfortunate.
Change:
Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a <del> link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. </del> <ins> physical or virtual link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. </ins> Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect.

Discussion:
Also add Linda to ACKs and add stream: IETF (this is now an XML2RFCv3 thing)
From NAME
responding to the application-level feedback that indicates a bottleneck link somewhere along the path. We agree that "link" is ambiguous. In this section, we're talking about a bottleneck, so we don't need to to say "link", BUT we will clean up other occurrences of "link" in the document - one is actually a URL. implementing some forms of congestion control that probe for bandwidth. The conclusion says that the QoE is poorer when the two methods don't coordinate. Question 2: Both methods are implemented on the Media server, they should coordinate by nature, aren't they? You might think so, but they don't, for various reasons (transport protocols being implemented by OS vendors, and media servers and players are implemented by completely different people. We say that in 3.2, but we describe media servers as "implementing transport protocols". That should have been "rely on". This might change, with transport protocols being implemented in user space and packaged as libraries that are shipped media servers, but that's the case today.
Change:
The configuration agent selects a length for the server ID encoding. This length MUST have enough entropy to have a different code point <del> for each server. </del> <ins> for each server.  The length MUST be no more than 15 octets to provide sufficient entropy for server use. </ins> It also assigns a server ID to each server.

Discussion:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.
Change:
(EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF <del> to be used with the PSK MUST also be provisioned.  Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in RFC4086.  Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder. The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie-Hellman key establishment. </del> <ins> hash algorithm to be used with the PSK MUST also be provisioned. Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in RFC4086.  Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder.  The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie- Hellman key establishment. </ins> 2.3.

Discussion:
HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm.
Change:
provided to clients and having the resource check that requests have the same string in their "url" header parameter. <del> 6.4.1. </del> <ins> 6.3.1. </ins> The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL. <del> 6.5. </del> <ins> 6.4. </ins> In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
followed: The port value is set to the port of the default ICE candidate for <del> this m= section, but given that no candidates have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del> <ins> this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the

Discussion:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm
Change:
7.1. This section shows a very simple example that sets up a minimal audio <del> / video call between two JSEP endpoints and does not use trickle ICE. The example in the following section provides a more realistic example of what would happen in a normal browser to browser connection. The flow shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete.  Trickle ICE is not used.  Both Alice and Bob are using the default policy of balanced. </del> <ins> / video call between two JSEP endpoints without using trickle ICE. The example in the following section provides a more detailed example of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  Both Alice and Bob are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </ins> The SDP for |offer-A1| looks like:

Discussion:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward
Change:
For now, infer from other connectivity events and path_challenge/ path_response frames <del> 4.9. </del> <ins> 4.8. </ins> Importance: Extra

Discussion:
Connection retried was never properly specced. The main reason is that a retried connection is completely separate from the original connection attempt, except for the value, and as such is usually logged in a separate file / separate context from the original connection qlog data. Current qlog deployments either have other ways of correlating retried connections with the original attempts, or don't need to do this. Either way, there is no tangible need for at this time.
I don't think that's correct. You also take your Connection IDs with you to the new connection. quic-go logs it to the same file, as it is the same connection attempt. I don't see value in though.
Change:
arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. <del> It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  However, Initial and Handshake secrets are discarded as soon as handshake and 1-RTT keys are proven to be available to both client and server; see Section 4.9.1 of QUIC-TLS. </del> <ins> It is expected that keys are discarded at some time after the packets encrypted with them are either acknowledged or declared lost. However, Initial and Handshake secrets are discarded as soon as handshake and 1-RTT keys are proven to be available to both client and server; see Section 4.9.1 of QUIC-TLS. </ins> 7.

Discussion:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!
Change:
and a public signature key.  Ownership of a client by a user is determined by the fact that the user has knowledge of the associated secret values.  When a client is part of a Group, it is called a <del> Member and its signature key pair uniquely identifies it to other clients or members in the Group.  In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this. Users will often use multiple clients, potentially one or more per device (phones, web clients or other devices...), and may choose to authenticate using the same signature key across devices, using one signature key per device or even one signature key per group. </del> <ins> Member.  In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this. Users will often use multiple devices, e.g., a phone as well as a laptop.  Different devices may be represented as different clients, with independent cryptographic state, or they may share cryptographic state, relying on some application-provided mechanism to sync across devices. </ins> The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group

Discussion:
Mainly focused on cleaning up grammar, but also fixing some things that have gone stale, like the idea that the MLS protocol is "abstract".
This looks good ! Thank you !
Looks good! Just two comments on client identity.
Change:
Clients provide the following as input to the issuance protocol: <ins> Issuer Request URI: A URI to which token request messages are sent.  This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL.  The value of this parameter depends on the Client configuration and deployment model.  For example, in the 'Split Origin, Attester, Issuer' deployment model, the Issuer Request URI might be correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer. </ins> Issuer name: An identifier for the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer.

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
there are many Attesters owned, the use of an Endorser becomes more scalable. <del> That is, it might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer </del> <ins> That is, a Verifier might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer </ins> firmware or software is true.  A stronger level of assurance of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to

Discussion:
Signed-off-by: Dave Thaler
What is the “it” in “That is, it”