jiebi/CodeConvo huggingface dataset:
Change:
Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality. <del> In the HTTP responses, the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response.  Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </del> <ins> A DNS response may contain a set of DNS Resource Records each with its own Time To Live (TTL) freshness information.  The freshness lifetime (RFC7234 Section 4.2) of the HTTP response should be coordinated with the Resource Record bearing the smallest TTL in the response.  The freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response. Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </ins> A DNS API Server MUST be able to process application/dns- udpwireformat request messages.

Discussion:
closes issue
NAME thanks.
The draft says "the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response", which might not be strong enough. A SHOULD might be OK for shorter, but allowing the value to increase might be unwise, depending on the caching model.
agree
Seems like it should be MUST:
some typos, also, I can't seem to parse 1 of the sentence.
Change:
2.4. <del> The Captive Portal Enforcement component restricts the network access of User Equipment according to site-specific policy.  Typically User </del> <ins> The Enforcement Device component restricts the network access of User Equipment according to site-specific policy.  Typically User </ins> Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. <del> The Captive Portal Enforcement component: </del> <ins> The Enforcement Device component: </ins> 2.5.

Discussion:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?
Change:
Framework and Data Model for OTN Network Slicing <del> draft-ietf-ccamp-yang-otn-slicing-00 </del> <ins> draft-ietf-ccamp-yang-otn-slicing-01 </ins> Abstract

Discussion:
Updated README: Aligned URLs with the new location of the repository Added information about CCAMP WG weekly calls Changed I-D version to -01 (-00 has been already published) Delete draft-zheng-ccamp-yang-otn-URL no longer needed to be kept in the repository (still available in GitHub commit history
Change:
A component embedded in a representation that identifies a resource for future hypermedia interactions, such as a link or a form.  If the client engages in an interaction with the identified <del> resource, the result may be a change resource state and/or application state. </del> <ins> resource, the result may be a change to resource state and/or client state. </ins> A method where multiple identical requests with that method lead to the same visible resource state as a single such request.  For

Discussion:
Addressing issue
Thanks Ari :) I will do a final pass and merge.
Originally, application state defined the state kept on the client, that is, what Web page is currently rendered and which pages were visited before. This does not make sense anymore when resource state is more than static Web pages, but parameters, physical state, etc. "Application state" logically would mean the state of the overall IoT application (state of the client and resoource state).
Related comment by Mike Amundsen:
I would add a comment in the definition, that this is called "Application State" in Fielding's thesis, but has some ambiguity in mordern (IoT) applications, where resource state is very dynamic and reflects part of the state in which the overall application is.
Change:
resolved time value and name are matched.  Similarly, when unit is given, only the SenML Records with equal resolved unit and name are matched.  If both time and unit are given in the Fetch Record, both <del> MUST to match for the SenML Record to match. </del> <ins> MUST to match for the SenML Record to match.  Each Target Record MUST be included in the response only once, even if multiple Fetch Records match with the same Target Record. </ins> For example, if the IPSO resource "5850" would have multiple sensor readings (SenML Records) with different time values, the following

Discussion:
Patch records must match only one Target record Invalid records result in error No Pack state is changed if any invalid records Also: Noted Fetch response must contain each target only once Updated author info
Change:
"LogicalType" is an abstraction of the result of a "logical-expr". Its two instances, "LogicalTrue" and "LogicalFalse", are not <del> related to the JSON literals "true" and "false" and have no </del> <ins> related to the JSON literals "true" and "false" and have no direct </ins> syntactical representation in JSONPath. "NodesType" is an abstraction of a "filter-path" (which appears in a test expression or as a function argument).  Members of <del> "NodesType" have no syntactical representation in JSONPath. </del> <ins> "NodesType" have no direct syntactical representation in JSONPath. </ins> The abstract instances above can be obtained from the concrete representations in tbl-typerep.

Discussion:
There are some syntactical representations, e.g.: LogicalTrue can be represented by (1==1). LogicalFalse can be represented by (1==0). Nothing can be represented by a query that always returns the empty nodelist, such as $[?1==0]. But these are somewhat circuitous rather than direct. See URL
NAME I also considered deleting the statements about there being no (direct) syntactical representation of the values of certain types because I'm not sure they add much. The text in this PR adds an air of mystery - what are "direct syntactical representations"? WDYT?
I'm not sure how "direct" clarifies "syntactical representation." Either something can be represented in the syntax or it can't. Merge if you like.
This is obviously an improvement. We also could say "literals", but then we would assume knowledge about this programming language construct. So I think this should simply be merged.
Change:
QUIC.  For example, a non-compliant DCID might be converted to an integer and divided by the number of servers, with the modulus used to forward the packet.  The number of servers is usually consistent <del> on the time scale of a QUIC connection handshake. </del> <ins> on the time scale of a QUIC connection handshake.  See also version- invariance. </ins> Load balancers SHOULD drop packets with non-compliant DCIDs in a short header.

Discussion:
Carefully phrased language that considers NAME 's suggestion that SCID may not be stable across versions, and tries to suggest (IP, port, DCID) as a suitable long header hash without making promises on behalf of quic-invariants.
NAME sayeth on the list: It would be useful to include something like this in Section 4 as a non-normative hint on what fields to use, since our hint currently consists of an example that just uses the DCID. Similarly, make that assumption clearer in Section 8.
For what it's worth, Google's load balancer only uses destination CIDs for routing. We always pick 64bit CIDs during the handshake so we can assume that short headers always carry 64bit CIDs.
Do all CIDs resolve to a valid server ID?
NAME do you not care about an attacker specifically crafting destination CIDs to attack a particular server?
NAME We do not have a concept of server ID, but yes every CID routes to a server. NAME We do not care about that attack. I haven't seen any indication that it can actually cause harm in real life.
NAME very well, then you have no non-compliant DCIDs. You would only need to upgrade your LBs for new versions if they allowed client-chosen DCIDs < 8 bytes.
Change:
considerations. The server encrypts the server ID using exactly the algorithm as <del> described in stream-cipher-load-balancer-actions, performing the </del> <ins> described in encrypted-short-load-balancer-actions, performing the </ins> three passes in reverse order. 5.3. <del> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </del> <ins> The Encrypted Long CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, protects the server ID with a single encryption pass.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </ins> 5.3.1.

Discussion:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.
Change:
WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del> <ins> replying with a 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </ins> From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del> <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count

Discussion:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!
Change:
RTCP transmission for this m= section to use reduced-size RTCP, as specified in RFC5506. <del> If the directional attribute in the answer is of type "sendrecv" or "sendonly", choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del> <ins> If the directional attribute in the answer indicates that the JSEP implementation should be sending media ("sendonly" for local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to

Discussion:
BLOCKER: The final bullet of page 68 refers to answer directionality of "sendrecv" and "sendonly." These are incorrect when applying remote answers, for which these should be "sendrecv" and "recvonly." Please rephrase in terms of whether media is to be sent, or fix in some other way that doesn't get the sense reversed for remote answers.
Change:
binary code.  This extended key purpose does not introduce new security risks but instead reduces existing security risks by providing means to separate other extended key purposes used for <del> communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross-protocol attacks. </del> <ins> communication protocols namely, TLS (id-kp-clientAuth) or S/MIME (id- kp-emailProtection) etc.  in order to minimize the risk of cross- protocol attacks. </ins> To reduce the risk of specific cross-protocol attacks, the relying party or relying party software may additionally prohibit use of

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."
Change:
QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation <del> (see version-negotiation).  All other version numbers are potentially valid. </del> <ins> (see vn).  All other version numbers are potentially valid. </ins> The properties described in this document apply to all versions of QUIC.  A protocol that does not conform to the properties described

Discussion:
Or MAY, but let's leave this probabilistic, because in practice there is no uncertainty: packets are protected. I've changed the header of the section because it isn't just about the header: the subsections are about the specific headers, but this one is about packets as a whole.
Change:
Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting data back to the Message Framer, which will in turn send it to the <del> next protocol.  To improve performance, implementations SHOULD ensure </del> <ins> next protocol.  To improve performance, implementations should ensure </ins> that there is a way to pass the original data through without copying.

Discussion:
Two items here: Normative MUST? I guess this is just a guidance document so doesn't need anything normative. There's some later "should" as well which I would generally ask the same question for. but... here we have some NORMATIVE language. That SHOULD should probably be non-capitalised to align with earlier usage. (and so on later in the document, e.g. in the SCTP description)
The first one can just be "uses the default values", without normative text. Second one can be lowercase as well. SCTP has normative SHOULDs and MUSTs that can be removed.
Change:
3.1.3. <ins> QUIC ends a loss epoch when a packet sent after loss is declared is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. 3.1.4. </ins> QUIC ACKs contain information that is similar to TCP SACK, but QUIC does not allow any acked packet to be reneged, greatly simplifying implementations on both sides and reducing memory pressure on the sender. <del> 3.1.4. </del> <ins> 3.1.5. </ins> QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges.  In high loss environments, this speeds recovery, reduces spurious retransmits, and ensures forward progress without relying on timeouts. <del> 3.1.5. </del> <ins> 3.1.6. </ins> QUIC endpoints measure the delay incurred between when a packet is received and when the corresponding acknowledgment is sent, allowing

Discussion:
From a full read en route to Prague.
Thanks Jana, suggestions taken and "Clearer Loss Epoch" rewritten.
Change:
2.1. <del> The HTTP/3 specification is split into seven parts.  The document begins with a detailed overview of the connection lifecycle and key concepts: </del> <ins> The following sections provide a detailed overview of the connection lifecycle and key concepts: </ins> Connection Setup and Management (connection-setup) covers how an HTTP/3 endpoint is discovered and a connection is established.

Discussion:
I count eight including the additional resources or six not including them. But what I'm most concerned about is that Sections 1 and 2 are also part of the HTTP/3 specification.
Change:
precompute these obfuscated identities to ease the burden of trial decryption. <del> 9. </del> <ins> 10. </ins> This document makes no IANA requests.

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:
10 requests per second; <del> limited to 60 request per minute; </del> <ins> limited to 60 requests per minute; </ins> <del> limited to 1000 request per hour. </del> <ins> limited to 1000 requests per hour. </ins> Moreover system metrics, statistics and heuristics can be used to implement more complex policies, where the number of acceptable <del> request and the time window are computed dynamically. </del> <ins> requests and the time window are computed dynamically. </ins> 1.2.

Discussion:
reformats goals
to reorganize Goals section with a single type of list
Single type of list as in using the same list styling for goals and non-goals? Or leaving just the list of goals and use prose for non-goals?
Change:
record is called the "RDATA", and the authoritative answer bit is often called "the AA flag" or "the AA bit". <ins> A class "identifies a protocol family or instance of a protocol" (Quoted from RFC1034, Section 3.6).  "The DNS tags all data with a class as well as the type, so that we can allow parallel use of different formats for data of type address."  (Quoted from RFC1034, Section 2.2).  In practice, the class for nearly every query is "IN".  There are some queries for "CH", but they are usually for the purposes of information about the server itself rather than for a different type of address. </ins> The most commonly-used rough definition is that the QNAME is a field in the Question section of a query.  "A standard query specifies a target domain name (QNAME), query type (QTYPE), and

Discussion:
I like the additional wording. I'll add it and take the question to the chairs to take to the WG.
Good catch on "DNS over TLS" -> "DNS over HTTPS". I didn't go with "DNS Queries over HTTPS" because it doesn't really describe the protocol.
Simple mistake: "DNS over TLS" should be "DNS over HTTPS" at line 1040. Or "DNS Queries over HTTPS" may be better because it is a draft name.If we're going to add class here, then I think (1) we need to go back to the WG and (2) we need to add something: "In practice, the class for nearly every query is IN. There are some queries for CH, but they are usually for the purposes of information about the server itself rather than for a different type of address" I wrote a doc some time ago attempting to deprecate class, because of the way it keeps popping up as though it is viable.
Change:
stream id assignment procedure described above.  If there are not enough streams available, ADD_STREAM.SCTP must be called. <del> When this value is changed, or a Message with Message Property "msgPriority" is sent, and there are multiple Connection objects assigned to the same SCTP association, CONFIGURE_STREAM_SCHEDULER.SCTP is called to adjust the priorities of streams in the SCTP association. </del> SEND.SCTP.  Message Properties such as "msgLifetime" and "msgOrdered" map to parameters of this primitive.

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!