jiebi/CodeConvo huggingface dataset:
Change:
Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a <del> server operating in Split Mode is not possible.  See cleartext-dns for more details regarding cleartext DNS. </del> <ins> server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
7. <del> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this feature SHOULD always send this Settings parameter to avoid leaking the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. </del> <ins> Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. </ins> 8.

Discussion:
The doc has evolved from just HTTP/3 Datagram, to define Capsule protocol and HTTP datagrams over capsule. In Security Considerations, we say It's a little ambiguous what "this feature" on face value. Arguably, the recommendation to always send the setting could be done in the section that defines the setting. Some editorial work would address these concerns.
Agreed
The intent is much clearer to me now, thanks!
Change:
Section 5). The m= line MUST be followed immediately by a "c=" line, as specified <del> in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </del> <ins> in RFC4566, Section 5.7.  Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </ins> I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when

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:
5. <ins> For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake. 6. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs. <del> 6. </del> <ins> 7. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same

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:
No outputs. <del> The client fetches the configuration state "server_id", </del> <ins> The Client fetches the configuration state "server_id", </ins> "ciphersuite", "commitment_id" associated with "server_origin". <del> The client makes an anonymous GET request to </del> <ins> The Client makes an anonymous GET request to </ins> "CONFIG_ENDPOINT"/.well-known/privacy-pass with a message of type "fetch-commitment" and a body of: <del> The server looks up the current configuration, and constructs a </del> <ins> The Server looks up the current configuration, and constructs a </ins> list of commitments to return, noting whether a key commitment is valid for issuance or redemption or both. <del> The server then responds with a message of type "commitment" and a </del> <ins> The Server then responds with a message of type "commitment" and a </ins> body of: <del> The client then verifies the signature for each key commitment and stores the list of commitments to the current scope.  The client </del> <ins> The Client then verifies the signature for each key commitment and stores the list of commitments to the current scope.  The Client </ins> SHOULD NOT cache the commitments beyond the current scope, as new commitments should be fetched for each independent issuance and <del> redemption request.  The client SHOULD verify the </del> <ins> redemption request.  The Client SHOULD verify the </ins> "inclusion_proofs" to confirm that the key commitment has been <del> submitted to a trusted registry. </del> <ins> submitted to a trusted registry.  Once the Client receives the "ciphersuite" for the Server, it should implement all Privacy Pass API functions (as detailed in draft-davidson-pp-protocol) using this ciphersuite. </ins> 5.

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
session: An association between a client and a server resulting from a handshake. <del> server: The endpoint which did not initiate the TLS connection. </del> <ins> server: The endpoint which did not initiate the DTLS connection. </ins> The reader is assumed to be familiar with the TLS 1.3 specification since this document defined as a delta from TLS 1.3.

Discussion:
Add references to RFC 768: UDP RFC 4347: DTLS 1.0 RFC 4346: TLS 1.1 RFC 6347: DTLS 1.2 RFC 5246: TLS 1.2 in the Introduction section. Currently they are mentioned but with no citations.
Change:
for RTCP transmission limits, and to avoid SRTCP compound packets with RTP translators and mixers. <del> 2.6. </del> <ins> 2.7. </ins> A system using EKT learns the SRTP master keys distributed with FullEKTFields sent with the SRTP, rather than with call signaling.  A

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
The PING frame can be used to keep a connection alive when an application or application protocol wishes to prevent the connection <del> from timing out.  An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended. This guidance SHOULD indicate whether it is the client or the server that is expected to send the PING.  Having both endpoints send PING frames without coordination can produce an excessive number of packets and poor performance. A connection will time out if no packets are sent or received for a period longer than the time negotiated using the max_idle_timeout transport parameter; see termination.  However, state in middleboxes might time out earlier than that.  Though REQ-5 in RFC4787 recommends a 2 minute timeout interval, experience shows that sending packets every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </del> <ins> from timing out; see defer-idle. </ins> 19.3.

Discussion:
This moves it up under the idle timeout section. As discussed on the issue, the HTTP draft is basically good.
The transport Draft states: This guidance was added to the HTTP Draft in , but was subsequently removed.
I guess that something to discuss in the applicability draft as well
Looks like made this text more generic, leaving the specifics of how to keep a connection alive (e.g. with PING frames) to the transport implementation. The text in question is now in Section 5.1: It's possible the transport draft needs a similar generalization, to recommend implementations expose a way for the application layer to control whether an connection is idle.
Actually there is a section on "Session resumption versus Keep-alive" in the applicability draft already. Do we need to say more? Is that needed in the transport draft as well?
On the whole, this is good. Might be worth having something a little stronger than "might provide"; that would be normative, but the old text already hinted fairly strongly that this was a capability that needed to be exposed to applications.
Change:
2.1. <del> The following information serves as the registration form for the "application/yaml" media type. </del> <ins> The media type for YAML text is "application/yaml"; the following information serves as the registration form for this media type. </ins> application

Discussion:
This might be a bit nitpicky, but I think the draft should explicitly say that contains YAML.
If you are ok with the integration, feel free to squash and merge NAME
Change:
associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to null.  RtpTransceivers that were created by applying a remote offer <del> that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del> <ins> that was subsequently rolled back MUST be stopped and removed from the PeerConnection.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method. This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or

Discussion:
Is there any other action to be taken for the issues mentioned in ?
NAME I concluded no.
Grouping these as one bug. Section 4.1.7.1 - the term "inactive" final answer is introduced without a defintion. Need to either define "inactive" or use another term. Section 4.1.7.2 Rollback - "and possibly the answerer as well" is wishy-washy. Suggest "and the answerer if it has done set-remote-description". Section 4.1.7.2 This is the first mention of "pending local / remote description". Suggest link to definition. Section 4.1.7.2 "RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed". The term "removed" is undefined. Deleted, discarded, destroyed or detached from the PeerConnection? Suggestion: "stopped and removed from the PeerConnection". (if the JS app still has a reference to them, it may still inspect the object).
LG % nit
Change:
After this point, any pending send operation is resumed to the bound peer address. <del> 4. </del> <ins> 5. </ins> <del> The example shown in fig-rrc-example illustrates a client and a server exchanging application payloads protected by DTLS with an unilaterally used CIDs.  At some point in the communication interaction the IP address used by the client changes and, thanks to the CID usage, the security context to interpret the record is successfully located by the server.  However, the server wants to test the reachability of the client at his new IP address, to avoid being abused (e.g., as an amplifier) by an attacker impersonating the client. </del> <ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC extension. </ins> <del> 5. </del> <ins> Once a connection has been established the client and the server exchange application payloads protected by DTLS with an unilaterally used CIDs.  In our case, the client is requested to use CID 100 for records sent to the server. At some point in the communication interaction the IP address used by the client changes and, thanks to the CID usage, the security context to interpret the record is successfully located by the server. However, the server wants to test the reachability of the client at his new IP address. 6. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker

Discussion:
Updated draft based on feedback from the working group. The following changes have been made: Usage of the TLS flags extension Enhanced IANA consideration section Expanded example section
added a few inline suggestions
Change:
3.1. To use this authentication mechanism, the client MUST possess a <del> certificate containing an ECDSA-capable public key and signed with ECDSA. </del> <ins> certificate containing an ECDSA-capable public key. </ins> The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify

Discussion:
TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key. TLS 1.2 removed this restriction. Since RFC 4492 predated TLS 1.2 it reflected the same restriction. Here we remove it.
Change:
signature can be computed.  Details on computing counter signatures are found in counter_signature. <del> This parameter provides the time the content cryptographic operation is performed.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content structure was created.  The unsigned integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970.  The field is primarily intended to be to be used for counter signatures, however it can additionally be used for replay detection as well. </del> The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional because they do not need to be in every map, headers required in

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
There are several ways that these assumptions can be violated, both by misconfiguration and by attack.  For example, on a web server that allows non-administrative users to write to .well-known, any user can <del> claim to own the server's hostname by responding to an HTTP </del> <ins> claim to own the web server's hostname by responding to an HTTP </ins> challenge, and likewise for TLS configuration and TLS SNI. The use of hosting providers is a particular risk for ACME

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
token management information, which the client instance will store in place of the values returned in (2). <del> 1.5.6. </del> <ins> 1.5.7. </ins> In this scenario, the client instance does not call an RS and does not request an access token.  Instead, the client instance only

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.
Change:
examples throughout these sections assume the use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple <del> Registration can not be executed as the base attribute (which is mandatory for HTTP) can not be used there.  In all definitions in </del> <ins> Registration cannot be executed as the base attribute (which is mandatory for HTTP) cannot be used there.  In all definitions in </ins> these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing this specification MUST support the discovery, registration, update,

Discussion:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.
Change:
This privileged position allows for richer feature extraction from encrypted data, which might improve traffic analysis. <del> can use padding to reduce the effectiveness of traffic analysis. </del> <ins> and can use padding to reduce the effectiveness of traffic analysis. </ins> Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message

Discussion:
Comment by NAME How would that work? How would the client consent? Or show awareness? Or become aware ? Can't the Target Resource also not use padding in the response? But I guess they wouldn't know about being connected to obliviously or regularly, unless the Client tells the server within its encrypted payload request? Eg if a regular https server sees a certain field, it would/could know to do some padding? (one would assume ohttp relays are fairly well known on static IPs anyway, so the Client wouldn't be revealing much if it could ask the http server itself for random padding
There are two questions here, delays and padding. Both are areas in which the specification is not prescriptive. This is deliberate, mostly because these are areas where a single strategy would be inadvisable. Application needs vary. Well, in any number of ways. A telemetry submission service (see also STAR) might provide greater privacy benefit from batching requests that are forwarded from the client to gateway. In that model, the client might tolerate arbitrary delay (see URL for example). In other cases, the client still cares about a response, but it might be willing to hang around for some time (10s, 30s) for an answer. How the client consents to delays can also vary. It could be part of terms of service that are negotiated when the use of the relay is arranged. That sort of arrangement might cover all these points. If you are looking for protocol mechanisms, we've discussed explicit signaling as an extension. A client could use something like (see ) to indicate that within the protocol[^1]. An explicit signal demonstrates awareness for those cases where the delay might be conditional. [^1]: Note also that this sort of signaling might imply a need for the relay to remove that field, though perhaps all clients add it and so it doesn't reveal anything if forwarded. Yes. Section 6.3 references back to this text, but it's worth mentioning the gateway too. There are many things that might feed into a padding strategy. Sometimes this is something the gateway will know because they are configured for a particular application and can look at the payload to determine how to best pad. Clients can probably signal (within encapsulation) what they might prefer, if that would help. Again, it's too application-specific to say much of use.

Martin, The comment it isn’t my comment. Maybe there is another Pwouters in github Kind regards Paul Verstuurd vanaf mijn iPad
My apologies. I definitely got the wrong person there.
thanks
Flipping to approve, with or without my suggestion. Sorry again for my confusion.
Change:
section for this media type or in the same bundle group as the first m= section for this media type. <ins> This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons.  This requires all m= sections in the bundle group to be rejected, as specified in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 7.3.3. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:

Discussion:
If an answerer rejects the "offerer tagged" m= section (the one listed first in "a=group:BUNDLE"), the BUNDLE spec requires rejecting all m= sections in the BUNDLE group. This means that stopping one transceiver between setting an offer and creating an answer may potentially cause multiple m= sections to be rejected. See: URL