jiebi/CodeConvo huggingface dataset:
Change:
2. Like HPACK, QPACK uses two tables for associating header fields to <del> indices.  The static table (see _table-static) is predefined and contains common header fields (some of them with an empty value). The dynamic table (see _table-dynamic) is built up over the course of the connection and can be used by the encoder to index header fields in the encoded header lists. </del> <ins> indices.  The static table (see header-table-static) is predefined and contains common header fields (some of them with an empty value). The dynamic table (see header-table-dynamic) is built up over the course of the connection and can be used by the encoder to index header fields in the encoded header lists. </ins> QPACK defines unidirectional streams for sending instructions from encoder to decoder and vice versa.

Discussion:
xml2rfc v3 format prohibits the use of these, which will cause problems. This makes the anchors longer, so feel free to go with something else.
Had to merge it, but feel free to fix anchors.
Change:
Abstract <del> JSONPath defines a string syntax for selecting and extracting values within a JSON (RFC 8259) value. </del> <ins> JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from a JSON value. </ins> 1. JSON RFC8259 is a popular representation format for structured data <del> values.  JSONPath defines a string syntax for identifying values within a JSON value. </del> <ins> values.  JSONPath defines a string syntax for selecting and extracting JSON values from a JSON value. </ins> JSONPath is not intended as a replacement for, but as a more powerful companion to, JSON Pointer RFC6901.  See json-pointer.

Discussion:
This is an attempt to make two sentences in the abstract and introduction less clunky while not jettisoning their precision.
Thanks NAME I see you managed to approve a draft PR - interesting.
Works for me, although one would need to understand that JSON values are nested to understand the abstract. (But we can't start from the creation of the universe.)
Change:
2.2. Here we discuss candidate mechanisms for provisioning the User <del> Equipment with the URL of the API to query captive portal state and </del> <ins> Equipment with the URI of the API to query captive portal state and </ins> navigate the portal. 2.2.1. <del> A standard for providing a portal URL using DHCP or Router </del> <ins> A standard for providing a portal URI using DHCP or Router </ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture <del> expects this URL to indicate the API described in section_api. </del> <ins> expects this URI to indicate the API described in section_api. </ins> 2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap <del> Information containing the URL for the JSON-based API described in </del> <ins> Information containing the URI for the JSON-based API described in </ins> section_api. 2.3.

Discussion:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.
Change:
ServerHello.cipher_suites, and the supported_versions extensions in the ClientHello and ServerHello would be omitted. <del> cTLS allows specialization along the following axes: The identifier for this profile, to be sent in the "profile_id" field of CTLSPlaintext records.  This value MUST NOT be zero.  If this value is not present, the default "profile_id" is 1. </del> <ins> The following elements are defined: </ins> <del> If present and set to true, the sequence number field is omitted from encrypted record headers. </del> <ins> identifies the profile being defined. </ins> indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3).

Discussion:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.
Change:
4.2.6. The "post_handshake_auth" extension is used to indicate that a client <del> is willing to perform post-handshake authentication post-handshake- authentication.  Servers MUST NOT send a post-handshake </del> <ins> is willing to perform post-handshake authentication (post-handshake- authentication).  Servers MUST NOT send a post-handshake </ins> CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension.

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
name: enable_multipath (TBD - experiments use 0xbabf) <del> value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : If the peer does not carry the enable_multipath transport parameter, which means the peer does not support multipath, endpoint MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document.  If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </del> <ins> value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : If the parameter is absent or set to 0, the endpoints MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits

Discussion:
Lack of the reference to Section 7.4/Section 7.4.2 of 9000 where the general handling of (new) transport parameters is discussed. When the new transport parameter is not present, this does not necessarily mean multipath is not supported as it can be supported, but disabled (for this connection as a function of local policy). I would update this text
The absence of the parameter does indeed indicate that the peer will not support multipath for this connection. But yes, the current text does not read too well. I think we should simplify and just say the same as QUIc V1, i.e. "Transport parameters have a default value of 0 if the transport parameter is absent". So something like:
The negotiation only refers to "support for this connection". We cannot make any statement about whether the same server might negotiate the feature in another connection attempt. There is no practical difference between "not supported" and "supported, but disabled". It could very well be for example that some server in a farm support the feature and some don't.
NAME please review PR
Looks good to me. Thanks.
Change:
IESG <iesg@ietf.org> <del> [RFCthis] </del> <ins> coaps-ws-scheme in [RFCthis] </ins> 9.6.

Discussion:
URL Ensure that all "Section N" references are updated.
URL Cl.8.5: I think it would be easier for IANA if the coaps+tcp and coap+tcp URI schemes were described like the websockets ones in 8.5.1 and 8.5.2. This is another case with a heavy dependency on RFC7252 references.
URL We need to fill in the template.
URL s/are potentially accessible/are intended to be accessible/ [Editor] Same language is used for coap+wss. [Editor] Ironically, "potentially accessible" was copied from CoAP Classic - RFC7252. ~
URL Cl.6.2: This indicates ABNF is used for the definitions. However clause 6.1.1 and 6.1.2 make no mention of the ABNF syntax or reference to RFC3986. The descriptions of the definitions of the URI schemes in 6.2, 6.1.1 and 6.1.2 should be harmonised. This could be more consistent. Currently, coap+tcp and coaps+tcp rely on references to coap and coaps in RFC7252: The semantics defined in [RFC7252], Section 6.1, apply to this URI scheme, with the following changes and require that the reader is also familiar with URL The syntax of the "coap" and "coaps" URI schemes is specified in this section in Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of "host", "port", "path-abempty", "query", "segment", "IP-literal", "IPv4address", and "reg-name" are adopted from [RFC3986].
Additional feedback - URL CoAP URIs In this section, the terms "client" and "server" are used WRT the TCP connection, not WRT CoAP, and that may be very confusing. Maybe use different terms here (initiator/responder)? [Note from editor] - The terms are used in the coaps+tcp section on ALPN. Since there are already references to ClientHello and ServerHello perhaps it could be clarified with "TCP client" and "TCP server"? 6.1.

CoAP over TCP and TLS URIs Not sure this belongs here, but it also should apply to 6.2, so maybe move it up to 6. Ditto. s/potentially reachable/intended to be reached/ The following paragraph applies to 6.1.1, 6.1.2, and this subsection. (Move up to 6.) (They can't be in a CoAP request; not sure what the MUST NOT means. But again, this also applies to the TCP/TLS case.) 6.2.1. Decomposing and Composing URIs Wrong use of MUST. (MUST it be included or is this a MUST NOT if equal?) Ditto.
The outline for the URI scheme definitions needs to follow the guidance in URL which now requires:
Change:
signaling means that less information is visible to the network than is the case with TCP. <del> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer information.  However, it means in-network operations that depend on modification of data are not possible without the cooperation of an QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </del> <ins> Integrity protection can also simplify troubleshooting at the end points as none of the nodes on the network path can modify transport layer information.  However, it means in-network operations that depend on modification of data (e.g. see RFC9065 are not possible without the cooperation of an QUIC endpoint.  Such cooperation might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </ins> Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks

Discussion:
URL, I am not sure I get what this paragraph is supposed to mean. Number of things - first of all it is not clear that integrity protection actually simply the troubleshooting without defining that kind of troubleshooting we are referring to here and who is doing those, even though it is true that now network nodes cannot modify the transport layer information. we are making a statement that in-network operations depends on modification of data, what is the data here? payload? header information? both? I think here we can reference to the I-D.ietf-tsvwg-transport-encrypt to setup the background information required to parse the statement correctly. I am not sure how a proxy here can support modification of data. Yes, that is my read of this last of the statement. Hence, hence we might want to clarify what is the scope of this collaboration that we are referring to .
addressed by
Change:
If the client exceeds that limit, it MAY not be served. <del> The field value is </del> <ins> The field is a List Structured Field of positive length.  The first member is named "expiring-limit" and its syntax is "service-limit", while the syntax of the other optional members is "quota-policy" </ins> The "expiring-limit" value MUST be set to the "service-limit" that is closer to reach its limit.

Discussion:
uses structured fields based on NAME preliminary work: thanks!!!referencing the RFC distinguishing sf-item and sf-integer, since sf-integer do not support parameters whereas sf-item does retaining the intermediate syntaxes (quota-policy, quota-units, service-limit, ...)
LGTM, waiting on ack from NAME before merging.
NAME thanks for reviewing! Can we merge?
It's your draft :)
I take it for a YES :D
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
4.1. <del> The user agent includes the public key of the application server when requesting the creation of a push subscription.  This restricts use of the resulting subscription to application servers that are able to provide proof of possession for the corresponding private key. The public key is then added to the request to create a push subscription.  The push subscription request is extended to include a body.  The body of the request is a JSON object as described in RFC7159.  A "vapid" member is added to this JSON object, containing the public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url encoded RFC7515.  The media type of the body is set to "application/webpush-options+json" (see mime for registration of this media type). A push service MUST ignore the body of a request that uses a different media type.  For the "application/webpush-options+json" media type, a push service MUST ignore any members on this object that it does not understand. </del> <ins> A user agent that wishes to create a restricted subscription includes the public key of the application server when requesting the creation of a push subscription.  This restricts use of the resulting subscription to application servers that are able to provide proof of possession for the corresponding private key. The user agent then adds the public key to the request to create a push subscription.  The push subscription request is extended to include a body.  The body of the request is a JSON object as described in RFC7159.  The user agent adds a "vapid" member to this JSON object that contains a public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url encoded RFC7515.  The media type of the body is set to "application/webpush-options+json" (see mime for registration of this media type). A push service can ignore the body of a request to create a subscription that uses a different media type.  For the "application/ webpush-options+json" media type, a push service MUST ignore any members on this object that it does not understand. </ins> The example in ex-restrict shows a restriction to the key used in ex- push.  Extra whitespace is added to meet formatting constraints.

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
regeneration and each transceiver is operated in an uni- directional mode. <ins> Implemantations may support the change of the carrier frequency where the receiver may operate at a different optical frequency as the transmitter.  The transceiver mode is a property of the transceiver and is applied to the transmitter and the receiver. Therefore, the transceiver mode is the same for the two segments on the two sides of the 3R regenaretor realised by two transceivers operated in the uni-directional mode. </ins> Due to the fact that 3R regenerators are composed of an optical transponder pair, the capabilitiy whether an optical transponder can be used as a 3R regenerator is is added to the transponder

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:
are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. <ins> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the client provides the server with an invalid or unsupported contact URL, then the server MUST return an error of type "invalidContact", with a description describing the error and what types of contact URL the server considers acceptable. </ins> The server creates a registration object with the included contact information.  The "key" element of the registration is set to the public key used to verify the JWS (i.e., the "jwk" element of the JWS

Discussion:
As far as I am aware there has been no explicit use case for this and Boulder explicitly disallows URIs to be used. should be the only explicitly supported URI type in the spec and others should be left up to implementing CAs to document.
Conversation on-list went more in the direction of specifying that providing any contact with an unrecognized URI scheme should result in a hard error of . Renaming appropriately.
Change:
the request with its own key (not the client instance's key or the token's key). <del> The AS validates the access token value and the client instance's </del> <ins> The AS validates the access token value and the Resource Server's </ins> request and returns the introspection response for the token. The RS fulfills the request from the client instance.

Discussion:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 122ea374f78cfa417b0d1d80101e64990c448665 https://deploy-preview-11--gnap-resource-servers-editors-URL
Change:
smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter <del> with the name of ct and a value indicating the media-format used for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty. An empty value indicates the default application/dns-udpwireformat type (e.g. ct&body=...). </del> <ins> with the name of "ct" and a value indicating the media-format used for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty.  An empty value indicates the default application/dns- udpwireformat type (e.g. ct&body=...). </ins> When using the GET method the URI path MUST contain a query parameter <del> with the name of body.  The value of the parameter is the content of the request encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </del> <ins> with the name of "body".  The value of the parameter is the content of the request encoded with base64url RFC4648.  Using the GET method is friendlier to many HTTP cache implementations. </ins> The DNS API Client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client

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:
Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to <del> March 30 Comcast, </del> <ins> March 30, </ins> AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility <del> traffic ATT, and </del> <ins> traffic, and </ins> Verizon reported similar trends with video traffic up 36% over an <del> average day (pre COVID-19) Verizon. </del> <ins> average day (pre COVID-19)}. </ins> We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported

Discussion:
…nd update public discussion venues
I left the previous description of Sanjay Mishra's presentation, but removed the sub-references in that description (which included the problematic ATT reference).
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?
Change:
a per-connection basis.  Even when the spin bit is not disabled by the administrator, endpoints MUST disable their use of the spin bit for a random selection of at least one in every 16 network paths, or <del> for one in every 16 connection IDs.  As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths. </del> <ins> for one in every 16 connection IDs, in order to ensure that QUIC connections that disable the spin bit are commonly observed on the network.  As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths. </ins> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that

Discussion:
NAME notes: requiring the disabling of the spin bit on a fraction of connections is useful. This may be worth a sentence of explanation. My understanding is that this exists both to protect the ability of endpoints to opt out and to ensure that monitoring is robust when the opt-out is exercised.
Also to ensure that if the functionality is removed/changed in a future version of QUIC, we're only changing the percentage of traffic that enables it versus creating something new.