jiebi/CodeConvo huggingface dataset:
Change:
given conference.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as <del> defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </del> <ins> defined in I-D.draft-ietf-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </ins> 6.

Discussion:
Changed reference to Tunnel and added an (interim) reference to Roach's PERC signaling draft
Added the actual reference to ietf-roach-perc-webrtc in the body.
LGTM
Change:
with fast open (0-RTT data). Internet of Things (IoT) and devices with limited computational <del> capabilities.  The Constrained Application Protocol (CoAP) RFC7252 is a web transfer protocol intended for resource-constrained IoT devices.  It suggests use of the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite with DTLS for securing communication between CoAP clients and servers.  RFC7925 defines TLS and DTLS profiles for resource-constrained devices and requires compliant devices to support the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite. Wireless Networks.  The Control And Provisioning of Wireless Access Points (CAPWAP) protocol specification RFC5415 mandates support of TLS_PSK_WITH_AES_128_CBC_SHA and TLS_DHE_PSK_WITH_AES_128_CBC_SHA ciphersuites with DTLS for authentication between the centralized Access Controller (AC) and distributed Wireless Termination Points (WTPs).  Use of PSK ciphersuites are Ooptional when securing RADIUS RFC2865 with TLS as specified in RFC6614.  The Generic Authentication Architecture (GAA) defined by 3GGP in TR 133 919 V12.0.0 (https://www.etsi.org/deliver/ etsi_tr/133900_133999/133919/12.00.00_60/tr_133919v120000p.pdf) </del> <ins> capabilities.  RFC7925 defines TLS and DTLS profiles for resource- constrained devices and suggests the use of PSK ciphersuites for compliant devices. Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614. The Generic Authentication Architecture (GAA) defined by 3GGP </ins> mentions that TLS-PSK can be used between a server and user <del> equipment for authentication. </del> <ins> equipment for authentication GAA. </ins> Smart Cards.  The electronic German ID (eID) card supports <del> authentication of a card holder to online services with TLS-PSK. The German Federal Office for Information Security (BSI) describes how TLS-PSK authentication is utilized in the eCard-API-Framework specification (TR-03112-7:https://www.bsi.bund.de/SharedDocs/Downl oads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/TR- 03112-api_teil7.pdf?__blob=publicationFile&v=1).  EMV support for TLS-PSK I-D.urien-tls-psk-emv discusses how the identities and PSK attributes for TLS-PSK can be extracted from EMV cards. </del> <ins> authentication of a card holder to online services with TLS-PSK SmartCard. </ins> There are also use cases where PSKs are shared between more than two <del> entities.  Some examples are below: </del> <ins> entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova): </ins> <del> Group chats.s In this use-case, the membership of a group is </del> <ins> Group chats.  In this use-case, the membership of a group is </ins> confirmed by the possession of a PSK distributed out-of-band to the group participants.  Members can then establish peer-to-peer connections with each other using the external PSK.  It is

Discussion:
Moved links in use cases sections to references and made the text somewhat more concise. Added some initial text on known attacks.
Change:
4.6. <del> Both Simulcast RFC8853 and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. </del> <ins> Simulcast as per RFC8853 MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. </ins> If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according

Discussion:
From NAME Simulcast and scalable video coding Both Simulcast [RFC8853] and Scalable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent on the same SSRC), MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer/answer. [BA] K-SVC and “S” modes are different. K-SVC denotes the KEY and KEY_SHIFT modes, whereas “S” modes denote the encapsulation of multiple encodings within a single SSRC, as is supported in VP9 and AV1. Diagrams of the various modes are included in the WebRTC-SVC specification: URL Also, SVC is not negotiated within Offer/Answer in WebRTC. It is something that the encoder can just turn on. At least for temporal modes (L1T2, L1T3) ingester support can often be taken for granted. While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode, in practice there are VP9 and AV1 hardware decoders that cannot decode spatial scalability because they do not support spatial references (e.g. a P-frame at a higher resolution than the P or I frame that it references). This nasty little “wrinkle” required us to define the “spatialScalability” attribute in Media Capabilities, to allow applications to discover whether a (hardware) decoder supports spatial scalability or not: Media Capabilities URL Not sure if you want to get into this in the specification. Issues are most likely to be encountered where hardware-based transcoders are used (but in that scenario, spatial scalability probably wouldn’t be relevant anyway),
Change:
%%% Key Exchange Messages <del> The server_version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </del> <ins> The version, cipher_suite, and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </ins> Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake

Discussion:
client to implement because it knows what hash the server will select. Also clarify the language about HRR and Key Shares.
NAME is this what you had in mind?
I did consider bogus binders, but dropping seems more sensible, and it seems like the only impact of the bogus binder would be that if the server didn't follow a consistent rule, then you would get a handshake failure at the server. It's not like it could pick them in any case.
(Agreed. This version feels way less weird.)
NAME comments welcome
Change:
A "suffix-value" is limited to "3*8alphanum". <del> 3.3. </del> <ins> 2.3. </ins> Multi-character namespaces can be registered specifically for use in this format, see iana-cons.  The registration policy requires the

Discussion:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.
Change:
3.4. <del> When using HTTP/2 H2 or HTTP/3 H3, UDP proxying requests use HTTP pseudo-header fields with the following requirements: </del> <ins> When using HTTP/2 H2 or HTTP/3 H3, UDP proxying requests use Extended CONNECT.  This requires that servers send an HTTP Setting as specified in EXT-CONNECT2 and EXT-CONNECT3, and that requests use HTTP pseudo-header fields with the following requirements: </ins> The ":method" pseudo-header field SHALL be "CONNECT".

Discussion:
It's mentioned in the abstract and intro but I think it would be useful to remind people that there are prerequisites required to use extended CONNECT in the section that details the specific requirements.
Change:
1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) resumption, wherein </del> <ins> TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein </ins> PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was <del> done to simplify protocol analysis.  TLS 1.2, in contrast, has no such requirement, as a PSK may be used with any hash algorithm and the TLS 1.2 PRF.  This means that external PSKs could possibly be re- used in two different contexts with the same hash functions during </del> <ins> done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm and the TLS 1.2 PRF.  This means that external PSKs could possibly be re-used in two different contexts with the same hash functions during </ins> key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions.

Discussion:
Importantly, add details regarding incremental deployment, and clarify label values for non TCP-based variants of TLS.
Fixed in .
Fixed in .
Both endpoints must adopt importers for interoperability's sake.
Fixed in .
"TLS 1.3 supports pre-shared key s/resumption/authentication"
Fixed in .
Change:
Section 10, and Section 10.5.2 especially, apply to this use of the CONNECT method. <del> Http2Transport requires explicit opt-in through the use of a HTTP/2 </del> <ins> Http2Transport requires explicit opt-in through the use of an HTTP/2 </ins> SETTINGS parameter, avoiding potential protocol confusion attacks by ensuring the HTTP/2 server explicitly supports the WebTransport protocol.  It also requires the use of the Origin header, providing

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
7.3. <del> PERC has significant overhead over SFrame because the overhead is per packet, not per frame, and OHB (Original Header Block) which duplicates any RTP header/extension field modified by the SFU. PERCLITE <https://mailarchive.ietf.org/arch/msg/perc/ </del> <ins> RFC8723 has significant overhead over SFrame because the overhead is per packet, not per frame, and OHB (Original Header Block) which duplicates any RTP header/extension field modified by the SFU.  I- D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/ </ins> SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't use the OHB anymore, however it still does per packet encryption <del> using SRTP.  Below the the overheard in PERCLITE implemented by Cosmos Software which uses extra 11 bytes per packet to preserve the PT, SEQ_NUM, TIME_STAMP and SSRC fields in addition to the extra MAC tag per packet. </del> <ins> using SRTP.  Below the the overheard in I-D.murillo-perc-lite implemented by Cosmos Software which uses extra 11 bytes per packet to preserve the PT, SEQ_NUM, TIME_STAMP and SSRC fields in addition to the extra MAC tag per packet. </ins> OverheadPerPacket = 11 + MAC length Overhead bps = PacketPerSecond * OverHeadPerPacket * 8 Similar to SFrame, we will assume the HBH authentication tag length will always be 4 bytes for audio and video even though it is not the <del> case in this PERCLITE implementation </del> <ins> case in this I-D.murillo-perc-lite implementation </ins> 7.3.1.

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
9. <del> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </del> <ins> DNS over HTTPS relies on the underlying HTTPS connection to provide confidentiality.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for confidential transport. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with

Discussion:
Separate out confidentiality and authentication - -01 said "Running DNS over HTTPS relies on the security of the underlying HTTP connection." This PR clarifies that the HTTPS connection can only provide confidentiality and authentication of the DNS API server. Clients wanting authentic DNS answers need to perform DNSSEC validation or explicitly trust the DNS API server.
I reverted this because my comment above was not satisfied before merge.
pr did some of this but was backed out. see that diff and discussion
I agree with the notion of separating transport security from e2e validation.. but I think the changes overshoot a touch. I would leave the first paragraph alone - https provides more than confidentiality and I don't think the text suggests anything other than doh relies on https. I like your second paragraph - though if we leave the first one in tact you probably want to remove the "also authenticates" part.. it can be recast as transport security between api server and client vs e2e validation
Change:
3.1.9. <del> The "RedemptionMessage" struct consists of the data that is sent by </del> <ins> The "RedemptionRequest" struct consists of the data that is sent by </ins> the client during the redemption phase of the protocol (redemption- phase). 3.1.10. The "ServerRedemptionResponse" struct corresponds to a boolean value <del> that indicates whether the "ClientRedemptionMessage" sent by the </del> <ins> that indicates whether the "ClientRedemptionRequest" sent by the </ins> client is valid.  It can also contain any associated data. 3.2.

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
Implement some form of batch-to-report index, as well as inter- and intra-batch replay mitigation storage, which includes some way <del> of tracking batch report size with optional support for state offloading.  Some of this state may be used for replay attack mitigation.  The replay mitigation strategy is described in anti- replay. </del> <ins> of tracking batch report size.  Some of this state may be used for replay attack mitigation.  The replay mitigation strategy is described in anti-replay. </ins> Beyond the minimal capabilities required of helpers, leaders are generally required to:

Discussion:
This is a follow-up to , removing a few dangling references to the helper state blob.
Change:
field. If the server already has a registration object with the provided <del> account key, then it MUST return a 409 (Conflict) response and provide the URI of that registration in a Location header field. This allows a client that has an account key but not the corresponding registration URI to recover the registration URI. </del> <ins> account key, then it MUST return a 200 (OK) response and provide the URI of that registration in a Content-Location header field.  This allows a client that has an account key but not the corresponding registration URI to recover the registration URI. </ins> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms

Discussion:
It seem like the only way to retrieve an existing registration object for a given key is to provoke an error by attempting to register again with the same key and read the Location from it. As a client library implementor, I would expect to and to not be recoverable. I think its strange that the only way to recover the registration object is by triggering an error. Would it make sense to add an extra endpoint to simply retrieve the registration object? Alternatively, I don't see any reason for the endpoint not to return when already registered (instead of when it create the registration) as opposed to a . Also, the returned error type in boulder is , which does not make much sense to me since the request was not malformed. If its an expected behaviour to provoke an error to recover data from the response, the error type should be specify into the spec and unique so its can be recovered from easily. Implementation in boulder and initial discussion in the ruby .
Change:
corresponds to the old path.  Additionally, a timer T, see timer- choice, is started. <del> The peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on the preference of the path through which the message was received: </del> <ins> If the path is still functional, the peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on whether the path through which the message was received is the preferred one or not anymore: </ins> If the path through which the message was received is preferred, a "return_routability_check" message of type

Discussion:
factor out common text remove the spurious "address confirmation failure": path validation only fails on timeout provide further rationale for choosing between basic and enhanced
We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if: you need to minimise implementation complexity you have privacy concerns -- i.e., to avoid providing a clear correlation signal off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path
In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that. If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives." If not, we should say what we mean by "address confirmation failure."
Change:
empty EAP-Response to the EAP-Request containing the TLS close_notify alert, the EAP-TLS server sends EAP-Success. <del> In the case where EAP-TLS with mutual authentication is successful (and neither HelloRetryRequest nor Post-Handshake messages are sent) the conversation will appear as shown in figbase1. </del> <ins> figbase1 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest nor Post-Handshake messages are sent). </ins> 2.1.2.

Discussion:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.
Change:
The grease_quic_bit transport parameter (0x2ab2) can be sent by both client and server.  The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST <del> treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. </del> <ins> treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC

Discussion:
Broken into separate changes; see the commentary on each. This won't rebase nicely with , but I can manage that later.
Change:
DelegationUsage ::= BIT STRING { allowed (0) } <del> Conforming CAs MUST mark this extension as non-critical.  This would allow the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </del> <ins> Conforming CAs MUST mark this extension as non-critical.  This allows the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </ins> 5.

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
as possible.  Endpoints MUST NOT send a RequestConnectionId message when an existing request is still unfulfilled; this implies that endpoints needs to request new CIDs well in advance.  An endpoint MAY <del> ignore requests, which it considers excessive (though they MUST be acknowledged as usual). </del> <ins> handle requests, which it considers excessive, by responding with a NewConnectionId message containing fewer than num_cid CIDs, including no CIDs at all.  Endpoints MAY handle an excessive number of RequestConnectionId messages by terminating the connection using a "too_many_cids_requested" (alert number 52) alert. </ins> Endpoints MUST NOT send either of these messages if they did not negotiate a CID.  If an implementation receives these messages when

Discussion:
Fix a deadlock identified by NAME This seems like it sets up a deadlock scenario. Consider peers A and B; A sends RequestConnectionId with num_cids=200 and B considers this request excessive, so ACKs it but sends no NewConnectionId in response. A is prohibited from sending another RequestConnection Id to indicate that it really needs new CIDs, since the requested 200 have not arrived yet; thus, B could end up not sending any NewConnectionIds even though A is essentially blocking on getting them. Unless "unfulfilled" is supposed to mean "not ACKed"?
NAME
Done.