jiebi/CodeConvo huggingface dataset:
Change:
value smaller than the "min_ack_delay" advertised by this endpoint is invalid. <del> Receipt of an empty ACK-FREQUENCY frame or invalid values in an ACK- FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.

Discussion:
Changed the error code to FRAMEENCODINGERROR and removed a condition for update which I think may end up causing correctness issues.
I removed the comment you thought was unnecessary, and we can discuss it and any other changes to the section separately.
Change:
section. Each "m=" section, provided it is not marked as bundle-only, MUST <del> generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </del> <ins> contain a unique set of ICE credentials and a unique set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </ins> For DTLS, all "m=" sections MUST use any and all certificates that have been specified for the PeerConnection; as a result, they MUST

Discussion:
This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM
Change:
Additional connection IDs are communicated to the peer using NEW_CONNECTION_ID frames (frame-new-connection-id).  The sequence number on each newly issued connection ID MUST increase by 1.  The <del> connection ID randomly selected by the client in the Initial packet and any connection ID provided by a Retry packet are not assigned sequence numbers unless a server opts to retain them as its initial connection ID. </del> <ins> connection ID that a client selects for the first Destination Connection ID field it sends and any connection ID provided by a Retry packet are not assigned sequence numbers. </ins> When an endpoint issues a connection ID, it MUST accept packets that carry this connection ID for the duration of the connection or until

Discussion:
The value the client puts in the Destination Connection ID field is not random, but unpredictable. But we could be clearer and just say what this refers to. The second error here was that the server can't use the value it puts in Retry. Rather than talk about retaining the values, I'm striking that clause.
Rob Wilton said:
This refers to the one instance where the connection ID does need to be randomly generated; see URL
Change:
5.1. <del> WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be used to bind the identity of the user of the endpoint to the fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate in the conference.  Similarly the Key Distributor can create a WebRTC </del> <ins> WebRTC Identity assertion I-D.ietf-rtcweb-security-arch can be used to bind the identity of the user of the endpoint to the fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate in the conference.  Similarly the Key Distributor can create a WebRTC </ins> Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor.

Discussion:
This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG
Change:
properties TLS does and does not provide and cannot safely rely on the latter. <del> Note in particular that the length of a record is not protected by encryption.  If this information is itself sensitive, application designers may wish to take steps (e.g., padding, cover traffic) to minimize information leakage. </del> <ins> Note in particular that the length of a record or absence of traffic itself is not protected by encryption unless the sender uses the supplied padding mechanism - see record-padding for more details. </ins> 5.1.

Discussion:
This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.
Change:
contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. <del> 7. </del> <ins> 6. </ins> The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime

Discussion:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.
Change:
solely up to the format, and not defined in this protocol. At the time this is published, the response types are works in <del> progress.  The only known response type is "application/dns- udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </del> <ins> progress.  The only response type defined in this document is "application/dns-udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </ins> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS(0) extensions, depending on the extension

Discussion:
minor editoral changes
thanks for these. The only one that's a little iffy is the inclusion of the reason phrase for 415... but I think here its giving more explanatory value than an impression that particular phrase needs to be used (which wouldn't jibe with http details).
Change:
hash function: The AEAD encryption and decryption functions are then composed of <del> individual calls to the CM encrypt function and HMAC.  The resulting </del> <ins> individual calls to the CTR encrypt function and HMAC.  The resulting </ins> MAC value is truncated to a number of bytes "tag_len" fixed by the ciphersuite.

Discussion:
I wasn't sure if CM was meant for "Counter Mode", if so, I thought using the standard terminology would be better... : )
I also originally got very confused by the CM acronym so definitely suggest taking the change.
NAME would you be able to rebase your commit?
NAME Should be good now. (~Note that I did not update the label in to avoid affecting the test vectors.~ Pushed a commit with updated test vectors.)
This PR looks good to me. I agree with the terminology change and the changes to the known-answer test generator. I re-ran the known-answer test generator locally and confirmed that it produced the test vectors in the PR.LGTM. This might conflict with URL depending on which PR gets merged first.
Change:
may need device-specific information such as a public key for the device or component or user on the device. <del> 8.3. </del> <ins> 7.3. </ins> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
7. <ins> This document requires no actions from IANA. 8. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the

Discussion:
PR for
IANA Considerations A. Must specify if IANA has to create a new registry or modify rules for an existing registry. B. Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C. See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) [RFC5237] (Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field,” February 2008.). In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) may help as well. D. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA."
Good catch. Do you want to take a shot at this? JSEP says
Not blocking for today's doc, to be clear.
Fixed by
Change:
[[OPEN ISSUE: are the rules below correct? https://github.com/tlswg/ tls13-spec/issues/451]] Prior to accepting the "early_data" <del> extension, the server MUST validate that the session ticket parameters are consistent with its current configuration.  It MUST also validate that the extensions negotiated in the previous </del> <ins> extension, the server MUST check the first PSK identity (see pre- shared-key-extension) corresponds to a valid ticket and validate that the session parameters are consistent with its current configuration. It MUST also validate that the extensions negotiated in the previous </ins> connection are identical to those being negotiated in the ServerHello, with the exception of the following extensions:

Discussion:
I would actually much rather we only offer one PSK identity since TLS 1.2 was perfectly fine offering just one and resumption has no use for offering multiple, but I suspect I will lose that fight. Absent that, at least make the protocol well-defined. Unlike both TLS 1.2 resumption and TLS 1.2 PSK, TLS 1.3 increases the state space and allows clients to offer multiple PSK identities. This mostly works, but 0-RTT presumes that only one is offered. Define 0-RTT to presume the first identity is selected and clarify that other shapes are possible due to the increased state space.
Change:
The frequency slot of the MC is defined by the n value defining the central frequency of the MC and the m value that defines the width of <del> the MC following the flexible grid definition in ITU-T Recommendation G.694.1 G.694.1.  In this model, the effective frequency slot as defined in ITU-T draft Recommendation G.807 is equal to the frequency slot of this end-to-end MC.  It is also assumed that ROADM devices can switch MCs.  For various reasons (e.g.  differential delay), it is preferred to use a single MC for all OTSi's of the same OTSiG.  It may however not always be possible to find a single MC for carrying all OTSi's of an OTSiG due to spectrum occupation along the OTSiG path. </del> <ins> the MC following the flexible grid definition in G.694.1.  In this model, the effective frequency slot as defined in G.807 is equal to the frequency slot of this end-to-end MC.  It is also assumed that ROADM devices can switch MCs.  For various reasons (e.g. differential delay), it is preferred to use a single MC for all OTSi's of the same OTSiG.  It may however not always be possible to find a single MC for carrying all OTSi's of an OTSiG due to spectrum occupation along the OTSiG path. </ins> 2.3.4.

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass
Change:
The Version Negotiation packet described in this document is not integrity-protected; it only has modest protection against insertion <del> by off-path attackers.  QUIC versions MUST define a mechanism that authenticates the values it contains. </del> <ins> by off-path attackers.  An endpoint MUST authenticate the contents of a Version Negotiation packet if it attempts a different QUIC version as a result. </ins> 8.

Discussion:
This clarifies that it is a mechanism in the target QUIC version that authenticates the information. This also lifts the strong requirement on authenticating the contents of Version Negotiation. QUIC version 1 does not do this and so does not comply with this requirement. The intent was always that only information that is used needs to be authenticated in this way. (This is a tiny bit of evasion as Version Negotiation is used in QUIC version 1 as a signal that a version is not supported, which results in clients abandoning connections.)
This is for -invariants-09: Section 6 says: Version Negotiation packets do not use integrity or confidentiality protection. A specific QUIC version might authenticate the packet as part of its connection establishment process. Is the second not contradicting what is said in previous paragraph: A Version Negotiation packet contains no other fields. So to my understanding the authentication that the paragraph above talks about needs to be done in another QUIC packet, it can't be done in a QUIC packet that is Version Negotiation. Can this be made more explicit or do I misunderstand and can you then clarify why this is not a contradiction?
I don't see this as contradictory. The sentence here: Implies that the version fields might be authenticated. Indeed, the document says that they MUST be authenticated (somehow). It doesn't say how. However, this ... means that it can't use any fields that are included in a Version Negotiation packet to do that. If you look at the current proposal for , that uses transport parameters.
Ok, then I would request a very minor tweak in this sentence: A specific QUIC version might authenticate the packet as part of its connection establishment process. So that it is explicit that is in another packet(s) than the Version negotiation packet. For example: A specific QUIC version might authenticate the version negotiation packet as part of its connection establishment process outside of this packet.
I have made a slightly larger tweak.
Change:
closing the connection.  The message takes up the remainder of the capsule, and its length MUST NOT exceed 1024 bytes. <del> A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the sender side.  If any additional stream data is received on the CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code H3_MESSAGE_ERROR.  The recipient MUST close the stream upon receiving a FIN.  If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it SHOULD send STOP_SENDING on the CONNECT stream. </del> <ins> An endpoint that sends a CLOSE_WEBTRANSPORT_SESSION capsule MUST immediately send a FIN.  The endpoint MAY send a STOP_SENDING to indicate it is no longer reading from the CONNECT stream.  The recipient MUST close the stream upon receiving a FIN.  If any additional stream data is received on the CONNECT stream after receiving a CLOSE_WEBTRANSPORT_SESSION capsule, the stream MUST be reset with code H3_MESSAGE_ERROR. </ins> Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent

Discussion:
After sending the CLOSEWEBTRANSPORTSESSION capsule and sending the FIN on the stream, it would make sense to also stop reading on the stream (by sending a STOP_SENDING). Should that be the recommended behavior in the spec?
Chair: discussed at IETF 114, consensus in the room to allow but not require sending STOP_SENDING
The spec currently reads: So it currently recommends setting a timer and then issuing a STOPSENDING. I guess the request here is to send indicate the sender of CLOSEWEBTRANSPORTSESSION may send the STOPSENDING immediately. I'm going to remove the bit about the timer since it's not really relevant? If the closing endpoint wants to wait to see if there's any other messages in flight on the CONNECT stream that's fine. The CLOSEWEBTRANSPORTSESSION + FIN + must-respond-with-FIN is an implicit STOP_SENDING.
Fix the typo, raise an issue for the other thing.
Change:
past day.  Attesters should not admit attestation types that result in small anonymity sets. <ins> The trustworthiness of attesters depends on their ability to correctly and reliably perform attestation during the issuance protocol.  However, in practice, certain types of attestation can vary in value over time, e.g., if the attestation process is compromised or maliciously automated.  These are considered exceptional events and require configuration changes to address the underlying cause.  For example, if attestation is compromised because of a zero-day exploit on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched. Addressing changes in attestation quality is therefore a deployment- specific task.  In Split Attester and Issuer deployments, Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow- lists. </ins> 3.2.2. Issuers MUST be uniquely identifiable by all Clients with a

Discussion:
cc NAME
Over a long enough timeline, attestations will be broken - through willful post-boot compromise, malware, or other means. Services that depend on attestations (consumers of access tokens) will observe clients that appear to pass attestation, but engage in behavior that indicates that the device is compromised (e.g. trigger thousands of interactions per second). As it stands, the service consuming access tokens is not able to provide feedback that these attestations appear to be false negatives, and should be re-examined by the attester. Even if this feedback were to be provided out of band, it will be challenging for the attester to identify which devices are compromised and diagnose the nature of the compromise. I do not anticipate that this will become a pressing issue until the initial attestations are compromised, but it may be helpful to plan ahead for this scenario.
Thanks, NAME This seems like something we ought to discuss in the architecture document.
Change:
purposes of this document they're considered network path properties <ins> It is worth pointing out explicitly, because questions about "Web Real-Time Communication", or "WebRTC", come up often, that some WebRTC protocols (RFC8834, RFC8835) are mentioned in this document, including RTP, WebRTC's principal media transport protocol.  However, (as noted in sd) it is difficult to give general guidance for unreliable media transport protocols, even in the specific case of WebRTC. </ins> 1.2. Note to RFC Editor: Please remove this section and its subsections

Discussion:
Check against new main version for duplication on scope.
Discussion from editor's conference call: find a better place to put description of WebRTC (now that we have a good scope section).
From NAME
NAME - please see what you think of the new location for the mention of WebRTC.
Sure, this seems fine.
Change:
Luminary example: Explain example addresses <ins> Multicast addresses in the examples were changed from ff35:30:2001:db8::x to ff35:30:2001:db8:f1::8000:x; the 8000 is to follow RFC 3307, and the f1 is for consistency with all the other example addresses where 2001:db8::/32 is subnetted to 2001:db8:x::/48 by groups of internally consistent examples. </ins> impl-info: Add note about the type being WIP Error handling: Place a SHOULD around the likely cases, and make

Discussion:
The generated address failed to follow the guidance of RFC 3307 and set the first bit of the Group ID.
Since the example prefix is 2001:db8::/32 , I would assume the plen field is also set to 32, so we would get: ff35:20:2001:db8::8000:x Or is there a reason here to use plen=0x30 (48) bits ?
Throughout the examples, we use the third word to distinguish between separate logically distinct examples (2001:db8:1:: .. 2001:db8:4::), so it seemed logical to take a /48 for this example as well. (Although in keeping with the other appendix that uses 2001:db8:f0::, something like 2001:db8:e0::/48 and thus ff35:30:2001:db8:e0::1 would enhance consistency).
Ok, thanks - I see - so in example nr 4 the prefix 2001:db8:4/48 is used, then the mcast address would become ff35:30:2001:db8:4::8000:x right? If the ':4' is omitted it looks like a prefix 2001:db8/32 is being used.
The last commit on this series (c4d24f38342a6a6e0074a26dfd88db302b62d47c) now has something in the original addresses 3rd word (2001:db8:f1::/48) to make the choice of 30 in the prefix length more understandable, and for consistency.
Change:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. <del> All EKT message other that ShortEKTField must have a length as </del> <ins> All EKT message other that ShortEKTField MUST have a length as </ins> second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.

Discussion:
s2.1, EKTMsgLength Should this be “MUST”: All EKT message other that ShortEKTField must have ...