jiebi/CodeConvo huggingface dataset:
Change:
triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. <ins> When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is set, calls to the createOffer API will generate new ICE credentials. This bit is cleared by a call to the setLocalDescription API with new ICE credentials from either an offer or an answer, i.e., from either a local- or remote-initiated ICE restart. </ins> When a new gathering phase starts, the ICE Agent will notify the application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply

Discussion:
From EMAIL: Question 1: Should this be interpreted literally, to mean "the next call, and only the next call to createOffer will generate new ICE credentials"? If so, there are various situations wherein one could encounter unexpected behavior. For example: Before createOffer is called, a remote offer is received that triggers an ICE restart. Should the next call to createOffer trigger another, superfluous ICE restart? createOffer is called twice, without setting the local description (and kicking off a new gathering phase). Should the second call generate new credentials, or only the first? I would propose a slight change, such as: "this will cause subsequent calls to createOffer to generate new ICE credentials, until a new gathering phase has started." This would more clearly represent the intent of the original rule, in my opinion. Question 2: The next paragraph states "Any changes to the ICE candidate policy also affect the next gathering phase, in similar fashion to the server changes described above." Does this mean that changes to the candidate policy will also cause an ICE restart, according to the same rules? I assume so, but figure it's worth asking.
On , any changes should set a needs-ice-restart bit, which is only cleared by setLD with new ICE credentials (although, possibly only by setLD + setRD, since the setLD could be rolled back) On , if the ICE policy is being made more restrictive, no ICE restart is needed. Obviously if less restrictive, then the needs-ice-restart bit will be set.
Both you proposed resolutions look good to me
Change:
Narrowly restricting the exposure opportunities for exploit at the AS in terms of time, place, and method makes exploit significantly more difficult, especially if the exception happens only once.  For <del> example, the AS can reject requests from the "previous_key" (or any previous one before it) to cause rotation to a new key, or at least ensure that the rotation happens to the same known key. </del> <ins> example, the AS can reject requests from the previously-bound key (or any previous one before it) to cause rotation to a new key, or at least ensure that the rotation happens to the same known key. </ins> See also the related considerations for token values in security- network-management.

Discussion:
To edit notification comments on pull requests, go to your .
The "previous_key" element added in is not necessary in practice because the AS should always be able to look up the current key value based on the access token, and the signature using the previous key proves possession of that key separate from any presentation of the key value or reference.
Makes sense
Change:
Abstract <del> This document provides an overview of the architecture of Transport Services, a model for exposing transport protocol features to applications for network communication.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines the common set of terminology and concepts to be used in definitions of Transport Services APIs and implementations. </del> <ins> This document proposal an architecture for exposing transport protocol features to applications for network communication, the Transport Services architecture.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines common terminology and concepts to be used in definitions of Transport Services APIs and implementations. </ins> 1.

Discussion:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.
Change:
In the diagram: <del> The Provisioning Service, API Server, and Web Portal Server are described as discrete functions.  An implementation might provide the multiple functions within a single entity. </del> <ins> The Provisioning Service, API Server, and User Portal are described as discrete functions.  An implementation might provide the multiple functions within a single entity. </ins> 3.

Discussion:
To replace "web-portal" and "Captive Portal Server" Address issue
Note: this actually fixed
Sorry, don't know where I got 45 from
Some reviewers have found "Captive Portal Server" to be confusing when read alongside "Captive Portal API Server". Let's change it to something a bit more distinct. Tommy Pauly has suggested "user portal", which seems reasonable. While we're in there, make sure we're consistent with this use. It was also pointed out that we used "web portal" in quite a few places (e.g. sec 2.6, section 4).
A reasonable URL
Change:
Encoding considerations: Must be encoded as using W3C.REC-xml- 20081126.  See RFC-AAAA for details. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del> <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any XML tags or attributes that they do not understand.  This allows

Discussion:
Alternatively we can have the same text 9 times instead of 8
Alexey confirmed in the CoRE session that this is OK, so let's go forward with this.
The IANA types review list explicitly wanted all of this repeated because they don't read the draft on the email and each type needs it's own email. It is insane. So I would not make this change. LGTM
Change:
The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 5.6.2. </del> <ins> 5.4.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce"

Discussion:
Move description of registration and authorization objects to Certificate Management section Re-frame Protocol Elements section to be more clearly about the transport layer Fix some references
Change:
5.9. <ins> The following steps are performed to apply a remote description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. <del> The following steps are performed at the media engine level to apply a remote description. </del> The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.

Discussion:
Plan is to write the text in the apply local/remote sections to indicate that upon an error, the session state should be restored to the pre-call state.
Change:
Data streams can be prioritized using any means suited to stream or request prioritization.  For example, see PRIORITY. <ins> Data streams are subject to the flow control mechanisms of the underlying layers (for example, HTTP/2 stream flow control, HTTP/2 connection flow control, and TCP flow control). </ins> 3.2. Definitions of new HTTP Upgrade Tokens can state that their

Discussion:
This adds a few statements through the text that explains that data streams are subject to any flow control provided by layers lower down. Wih that in mind, the potential for problem deadlocks should be clearer when we state it.
This is a non-blocking comment from AD review. I have no concerns if the authors choose to close it with no action. It might be worthwhile to discuss the interaction of stream flow control with capsule/datagram conversions. With other HTTP transactions, intermediaries can deliver whatever in-order bytes of the stream they have. When receiving capsules and emitting datagrams, if the stream flow control window is too small to accept the datagram size, there can be a deadlock. A sentence about this special case could avoid a silly implementer mistake.
I think this goes beyond just intermediaries. Instead it applies to any consumer of capsules where they might be tempted to try and buffer the capsule, in the data stream, in its entirety before processing or consuming it. That might be obvious as a "bad thing" for implementers that are already used to handling H2 or H3 frames. However, you identify that the DATAGRAM capsule is particularly tempting to buffer because it should be handled atomically. So I think it might help to briefly point out some deadlock considerations about flow window sizes in relation to capsule sizes, and processing / release of further window credits.
Adding a little bit of text to warn against such cases SGTM
Change:
"application/manifest+json" (appmanifest) and an "accept-language" header of "es-419". <del> Many bundles have a choice between identifying their manifest in this section or in their primary resource, especially if that resource is an HTML file.  Identifying the manifest in this section can help recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource. 4.2.4. </del> <ins> 4.2.3. </ins> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the

Discussion:
This PR removes the primary URL section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading. This and other removed sections can be defined in other documents in the future.
The subresource loading doesn't need a primary URL, but I think "Navigate to Bundle" use case still needs it. URL NAME NAME Please correct me if I am wrong. I'm assuming "Navigate to Bundle" uses a primary URL as a main resource URL.
That's correct. For a bundle to be navigable into, it needs to be possible to specify its main resource URL.
Yes, to open the web bundle file in the browser (eg: Drag and drop) we need either the primary URL or the manifest's . So, we need to keep either as an optional section.
The idea of this PR is that a primary URL could be defined in a separate section. However, it is outside the scope of the "core" bundle specification to define this section.
Thanks for making a PR! Could we see a path to having other document more clearly? Since we need a primary URL defined somewhere, it might be difficult to remove a primary URL section without a clear path how a primary URL is defined.
(Just in case if someone missed it) It seems this PR is one of agenda points at IETF 111 Wpack. URL
NAME : I just opened URL to discuss the possibility of creating an extension of the spec as a separate document.
LGTM (just for record). Thanks for working on this. Hello WPACK, My name is Felipe Erias. I am working on Web bundles at Igalia together with Dan Ehrenberg. I have just created several PRs at wpack-wg/bundled-responses and I am writing this email to request the addition of a point to discuss them to the agenda for the group's upcoming meeting at the end of July. These PRs address the removal of the primary URL section, the manifest section, and content negotiation. Most of this has been adapted from previous work by Dan on the WICG/webpackage repo. The overarching goal is to simplify the "core" Web Bundles specification so it includes just the minimal amount needed to support use cases like subresource loading. The removed sections may be defined in other documents in the future. These are the PRs: URL URL URL Best, Felipe
Change:
credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. <del> Each delegated credential is bound to a specific version of TLS and signature algorithm.  This prevents them from being used for other protocols or with other signature algorithms than service owner allows. </del> <ins> Each delegated credential is bound to a specific signature algorithm.  This prevents them from being used with other, unintended, signature algorithms. </ins> 2.2.

Discussion:
As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson
Change:
response formats will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY <del> have one or more EDNS extensions, depending on the extension definition of the extensions given in the DNS request. </del> <ins> have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP request- response pair.  The responses may be processed and transported in any

Discussion:
NAME my previous (deleted now) comment was in error in case you get a copy of that in email. sorry - git skillz failure on my part.
Change:
large without suffering any loss; this can misrepresent the true path properties, defeating methods such as DPLPMTUD. <ins> While DATAGRAM capsules can theoretically carry a payload of length 2 -1, most applications will have their own limits on what datagran payload sizes are practical.  Implementations SHOULD take those limits into account when parsing DATAGRAM capsules: if an incoming DATAGRAM capsule has a length that is known to be so large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. </ins> 5. Implementations of HTTP/3 that support HTTP Datagrams can indicate

Discussion:
In we discussed the risk presented by buffering extremely large datagram capsules. We should add some text to warn about this.
lgtm modulo nit
Change:
exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate <del> interface for the early exporter is RECOMMENDED. </del> <ins> interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </ins> If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as

Discussion:
We currently have which is a little confusing, since it doesn't note that the server has the non-early exporter available once it has generated its first flight, and doubly so since the actual motivation for separate interfaces is for security reasons of not accidentally using the early exporter when the main one is needed. (Split out from )
Change:
10.1. <del> IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </del> <ins> IANA is requested to add an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described <del> in the table below. </del> <ins> in the table below.  Although the value 53 has been allocated by early allocation for a previous version of this document, it is incompatible with this document.  Once this document is approved for publication, the early allocation will be deprecated in favor of this assignment. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document

Discussion:
Suggest a column name. Deprecate the old connection_id codepoint.
NAME
We currently have an early allocation of the TLS extensiontype codepoint 53 that was allocated on 2019-07-02. An implementation of the draft at that time will no longer interoperate with the current specification due to changes in how the MAC inputs and AAD are laid out. If we want to allocate a new extensiontype value for the new semantics, we should tell IANA that there is an existing early allocation and, e.g., that it should be left to expire (and what version of the draft to use as a reference until it does), with a new codepoint to be allocated in its stead. We also have the option to direct IANA that "once this document is approved for publication, the early allocation will be deprecated and the following assignment will be made".
I think we should take your last option.
See suggestion inline, though even as-is this is probably enough to cause the right things to happen at IANA and the RPC.
Change:
HTTP clients are expected to request that the transport keep connections open while there are responses outstanding for requests <del> or server pushes, as described in Section 19.2 of QUIC-TRANSPORT.  If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort </del> <ins> or server pushes, as described in Section 10.2.2 of QUIC-TRANSPORT. If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort </ins> maintaining a connection that might not be needed.  A gateway MAY maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers.  Servers SHOULD

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:
Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero- <del> length connection ID is also strongly recommended when migration is supported. </del> <ins> length connection ID is also strongly recommended when active migration is supported.  If a connection is intentionally migrated to new path, a new connection ID is used to minimize linkability by network observers.  The other QUIC endpoint uses the connection ID to link different addresses to the same connection and entity if a non- zero-length connection ID is provided. </ins> The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases.

Discussion:
This would be my proposal of a few small additions based on the discussion on list and at the last meeting (IETF-112) about privacy implications after migration regarding exposure of linkable user IP addresses to the server. The text doesn't give any recommendations but at least mentions it in the relevant sections.
I left a few suggestions, but this is heading in a good direction.