jiebi/CodeConvo huggingface dataset:
Change:
"user_cancelled", both of which indicate that the connection is not going to continue normally, see RFC8446. <del> In the case where the EAP-TLS server rejects the ClientHello with a fatal error, the conversation will appear as shown in figterm1.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see helloretry. </del> <ins> figterm1 shows an example message flow where the EAP-TLS server rejects the ClientHello with a Error alert.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see helloretry. </ins> <del> In the case where EAP-TLS server authentication is unsuccessful, the conversation will appear as shown in figterm2. </del> <ins> figterm2 shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert. </ins> <del> In the case where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server, the conversation will appear as shown in figterm3. </del> <ins> figterm3 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server and sends a TLS Error alert. </ins> 2.1.5. This is a new section when compared to RFC5216. <del> In the case where EAP-TLS is used without peer authentication (e.g., emergency services, as described in RFC7406) the conversation will appear as shown in figbase3. </del> <ins> figbase3 shows an example message flow for a succesfull EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in RFC7406). </ins> 2.1.6.

Discussion:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.
Change:
As this interaction mode is designed to facilitate interaction via a secondary device, it is not expected that the client instance <del> redirect the end user to the URL given here at runtime.  If the </del> <ins> redirect the end user to the URI given here at runtime.  If the </ins> client instance is capable of communicating an short arbitrary URI to the end user for use with the user code, the client instance can instead use the request-interact-usercodeuri method instead.  If the

Discussion:
Requires all URIs to be absolute throughout the protocol.
To edit notification comments on pull requests, go to your ._
While it doesn't say so in the spec and the example suggest otherwise, are relative URLs allowed for properties such as the response. Scenario, an implementation is deployed at a URL: URL The root of the server handles grant requests: to The application code that builds the response must be able to construct the full URL and therefor have knowledge of the host at which the application is deployed including any path prefix. This is not impossible, but in complex cloud deployments with load balancers and ingress services etc between the application code and the public endpoint this can get ugly. The current example from Section 3.1 of the spec. Implementations would be significantly easier to build if they could simply return:
To be clear, the base URL for any relative URL response would be the request URL.
Things get really tricky if you start to allow for things like directory ascension (../../continue) and other such things. Lots of attacks in the past stem from exploitation of devices like this. Application deployments that deal with external urls already have techniques for managing such urls, from proxy rewrites to internal configuration. With these together I don't see a good argument for this being anything but an absolute uri.
Is it necessary to state somewhere that all URIs are absolute?
Yes, we should say exactly that, that's why I am keeping this issue open. Thanks for pointing this out!
Makes sense
Change:
actively using N paths, the limit is reached.  If the client wants to start a new path, it has to retire one of the established paths. <del> ACK_MP frame mp-ack-frame can be returned via either a different </del> <ins> ACK_MP frame ack-mp-frame can be returned via either a different </ins> path, or the same path identified by the Path Identifier, based on different strategies of sending ACK_MP frames.

Discussion:
This should be a simple fix. There was only one place where MP_ACK appeared.
In the current draft, we are having two names of multi-path ACK. I think we should stick to just one.
I have a slight preference for ACKMP, on the model of ACKECN.
I submitted PR to fix this.
I would be consistent in how the I-D identifies MP additions vs. RFC9000. Given that the document uses MPCONNECTIONERROR and MPPROTOCOLVIOLATION, I have a preference for MP_ACK.
I added changes of the tag "mp-ack-frame" to "ack-mp-frame" for consistency...
Change:
1.3. <ins> The JSON value the JSONPath query is applied to is, by definition, a valid JSON value.  The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this specification.  Sections RFC8259 and RFC8259 of RFC8259 identify specific situations that may conform to the grammar for JSON texts but are not interoperable uses of JSON, as they may cause unpredictable behavior.  The present specification does not attempt to define predictable behavior for JSONPath queries in these situations. Specifically, the "Semantics" subsections of Sections name-selector, wildcard, filter-selector, and descendant-segment describe behavior that becomes unpredictable when the JSON value for one of the objects under consideration was constructed out of JSON text that exhibits multiple members for a single object that share the same member name ("duplicate names", see RFC8259).  Also, selecting a child by name (name-selector) and comparing strings (comparisons in Section filter- selector) assume these strings are sequences of Unicode scalar values, becoming unpredictable if they aren't (RFC8259). 1.4. </ins> A JSONPath expression is applied to a JSON value, the .  The output is a nodelist.

Discussion:
The text will be adjusted in a future PR.
This github bug is slowing me down a bit:
Huh! I'm not seeing that.
I'm only seeing it every second time I try to pull the repo state (issues, PRs) into emacs, which seems to use a graphql API. Annoying. This used to work well...
Thanks!
Change:
An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Discussion:
LGTM
lgtm
In URL 'certificates' is a set, and the PeerConnection selects which certificate to use. The SDP should have one 'a=fingerprint' line per certificate, and that is not reflected in the JSEP draft AFAICU.
Prague: One a=fingerprint line per cert, but we can go down to a single cert one DTLS has been established. The DTLS cert has to match one of the supplied a=fingerprints. (NAME correct as necessary)
PR added for allowing multiples. Processing rules go in the TBD applying section
Change:
Name: mqtt-permissions <del> Description/Specification: Permissions for MQTT client.  Tperm is a string with a value either "pub" or "sub". </del> <ins> Description/Specification: Permissions for MQTT client as defined in scope.  Tperm is an array of one or more text strings that each have a value of either "pub" or "sub". </ins> <del> Reference: [[This document]] (scope ) </del> <ins> Reference: [[This document]] (scope) </ins> 8.

Discussion:
Thanks Carsten! I'll go clear my DISCUSS :)
I see. These didn't cause a problem on my side.
Change:
unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. <del> Servers MUST drop other packets that contain unsupported versions. </del> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero- length connection IDs - the address tuple.  If the packet doesn't

Discussion:
Qualifies a MUST with an 'otherwise', since otherwise it would appear to directly contradict previous normative text.
Change:
firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information. <del> In those situations, the registrant needs to be careful to authenticate the RD as well.  The registrant needs to know in advance which AS, audience and scope values indicate an RD it may trust for this purpose, and cannot rely on the RD to provide AS address and token details.  (In contrast, in the other scenarios it may try to register, and follow the pointers the RD gives it as to which credentials it needs to provide in order to perform its registration). </del> <ins> In this case, the endpoint (and not the lookup clients) needs to be careful to check the RD's authorization. </ins> 7.4.

Discussion:
…om authorized RDs This makes the paragraph that described that for a particular case largely redundant. The lines about that special case that described special considerations for ACE anticipate a mechanism that is not finished yet, and were removed.
Change:
"token_key_id" is the least significant byte of the "key_id". <del> "blinded_msg" is the Nk-octet request defined above. </del> <ins> "blinded_request" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_msg)".  Ne is as defined in OPRF, Section 4. </ins> <del> The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below, where Nk = 48. </del> <ins> The value "tweaked_key" is stored locally and used later as described in finalization.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions: <del> The TokenRequest contains a supported token_type </del> <ins> The TokenRequest contains a supported token_type. </ins> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. <del> The TokenRequest.blinded_msg is of the correct size </del> <ins> The TokenRequest.blinded_msg is of the correct size. </ins> If any of these conditions is not met, the Issuer MUST return an HTTP 400 error to the Client, which will forward the error to the client.

Discussion:
draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME
Change:
determine the correct issuer domain name to use when configuring CAA records. <ins> If this field is present and set to "true", then the CA requires that all new-account requests include an "external-account- binding" field associating the new account with an external account. </ins> Clients access the directory by sending a GET request to the directory URL.

Discussion:
While addressing Dale's Gen-ART comments, it occurred to me that while the document said that a CA could require external account binding, it didn't say how. This PR adds a "meta" field and an error code to support that requirements proactively and reactively.
Merging based on NAME review
:ship:
Change:
this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they <del> produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </del> <ins> produce in an offer.  Because ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of

Discussion:
NAME I cleaned up as you suggested.
this is TCP Candidates with Interactive Connectivity Establishment (ICE)
We could have an informative reference for S 5.1.3 where we mention ICE can use UDP or TCP.
LGTM
Change:
more data on a given path than congestion control on that path allows.  This is already a requirement of QUIC-TRANSPORT. <del> Multipath TCP uses the LIA congestion control scheme specified in RFC6356.  This scheme can immediately be adapted to Multipath QUIC. Other coupled congestion control schemes have been proposed for Multipath TCP such as OLIA. </del> <ins> When a Multipath QUIC connection uses two or more paths, there is no guarantee that these paths are fully disjoint.  When two (or more paths) share the same bottleneck, using a standard congestion control scheme could result in an unfair distribution of the bandwidth with the multipath connection getting more bandwidth than competing single paths connections.  Multipath TCP uses the LIA congestion control scheme specified in RFC6356 to solve this problem.  This scheme can immediately be adapted to Multipath QUIC.  Other coupled congestion control schemes have been proposed for Multipath TCP such as OLIA. </ins> 5.

Discussion:
Some more text in the congestion control section explaining why coupled congestion control is suggested. We could later add SHOULD or MUST to request the utilization of coupled congestion control schemes for multipath QUIC.
Change:
HTTP includes state of the art standardized security mechanisms, and <del> HTTP can make use of already-deployed caching infrastructure. </del> <ins> HTTP can make use of already-deployed caching infrastructure such as CDNs (Content Delivery Networks), local proxies, and browser caches. </ins> Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport

Discussion:
…astructure
Looks good to me. I've been through the doc looking at occurrences of "cach", "prox", and "CDN", and they all looked fine to me.
Change:
6.1. <del> If a path has been verified to support ECN, QUIC treats a Congestion Experienced codepoint in the IP header as a signal of congestion. This document specifies an endpoint's response when its peer receives packets with the Congestion Experienced codepoint.  As discussed in RFC8311, endpoints are permitted to experiment with other response functions. </del> <ins> If a path has been verified to support ECN RFC3168 RFC8311, QUIC treats a Congestion Experienced(CE) codepoint in the IP header as a signal of congestion.  This document specifies an endpoint's response when its peer receives packets with the Congestion Experienced codepoint. </ins> 6.2.

Discussion:
And note that 8311 is an update.
(Broken out of .) >A receiver maintains a cumulative sum of It would have helped me, had this explained what was intended by “control violations” - I think it means to detect when the sender sends more than permitted by the flow control limit. I think the control part comes in a later sentence? (Is this measured against the largest advertised offset, or the current offset? … given what is written about reducing the advertised value?)
one suggestion, but I'm approving
Change:
provides congestion protection (low loss, assured latency, and limited reordering) leveraging MPLS Traffic Engineering mechanisms. <del> This document specifies the DetNet data plane operation and the on- wire encapsulation of DetNet flows over an MPLS-based Packet Switched Network (PSN).  The specified encapsulation provides the building blocks to enable the DetNet service and forwarding sub-layer functions and supports flow identification as described in the DetNet Architecture.  As part of the service sub-layer functions, this document describes DetNet node data plane operation.  It also describes the function and operation of the Packet Replication (PRF) Packet Elimination (PEF) and Packet Ordering (POF) functions with an MPLS data plane.  It also describes an MPLS-based DetNet forwarding sub-layer that eliminates (or reduces) contention loss and provides bounded latency for DetNet flows. MPLS encapsulated DetNet flows can be carried over network technologies that can provide the DetNet required level of service. This document defines examples of such, specifically carrying DetNet MPLS flows over IEEE 802.1 TSN sub-networks, and over DetNet IP PSN. The intent is for this document to support different traffic types being mapped over DetNet MPLS, but this is out side the scope of this document.  An example of such can be found in I-D.ietf-detnet-dp-sol- ip.  This document also allows for, but does not define, associated controller plane and Operations, Administration, and Maintenance (OAM) functions. </del> <ins> I-D.ietf-detnet-mpls specifies the DetNet data plane operation for MPLS-based Packet Switched Network (PSN).  MPLS encapsulated DetNet flows can be carried over network technologies that can provide the DetNet required level of service.  This document focuses on the scenario where MPLS (DetNet) nodes are interconnected by a IEEE 802.1 TSN sub-network. </ins> 2.

Discussion:
Similar structure and changes as in IP over TSN. Service protection interworking is out-of-scope.
Change:
Broker (RS) via the CONNECT control message after the TLS handshake. This is similar to an earlier proposal by Fremantle et al. fremantle14.  Alternatively, the token may be used for the TLS <del> session establishment as described in the I-D.gerdes-ace-dtls- </del> <ins> session establishment as described in the I-D.ietf-ace-dtls- </ins> authorize.  In this case, both the TLS PSK and RPK handshakes MAY be supported.  This may additionally require that the Client transports the token to the Broker before the connection establishment.  To this

Discussion:
fixed ID reference to ietf-ace-dtls-authorize doing this first so it'll build from makefile (
The correct reference is I-D.ietf-ace-dtls-authorize and not I-D.gerdes-ace-dtls-authorize.
Change:
A piece of asserted information, often in the form of a name/value pair.  Claims make up the usual structure of Evidence and other <del> RATS artifacts.  Compare /claim/ in RFC7519. </del> <ins> RATS artifacts.  Compare: /claim/ in RFC7519. </ins> A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and

Discussion:
Despite fixes in , Roman asks: [Roman's comments on -13] -- Section 4.1. In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean? -- Section 4.2. Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean? -- Section 4.2. Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean? I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear. In the natural language sense, that phrase doesn't parse. If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation). In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?
`
Change:
An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path- <del> abandon-close).  Note that while abandoning a path implies Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close).  However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time-close). </del> <ins> abandon-close).  Note that while abandoning a path will cause Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close). However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time- close). </ins> Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of

Discussion:
Minor tweak. The text says that a path abandon "implies" retirement of the CID. Readers could be mislead and assume that they don't need to send a retire frame after sending abandon, when in fact they do.
NAME , NAME NAME please review.
This Github setting is pretty annoying. NAME I understand why only the selected authors would be able to merge a pull request, but as it stands I am also blocked from requesting reviews of a PR that I just created.
LGTMThe proposed text is indeed clearer.
Change:
A user agent MAY omit the subscription set if it is unable to receive push messages in an aggregated way for the lifetime of the subscription.  This might be necessary if the user agent is <del> monitoring subscriptions for other clients (see sets-streams). </del> <ins> monitoring subscriptions on behalf of other push message receivers. </ins> The push service SHOULD return the same subscription set in its response, although it MAY return a new subscription set if it is

Discussion:
I ensured that the "proxy" text in UA and AS were similar. I removed the cross-references to and added text in Section 7.5, which is specific to PS policies if it doesn't want to support multiple subscription sets. I did not call out potential UA scenarios in detail other than "monitoring on behalf" of other receivers or senders. WebPush provides a mechanism to enable proxies - but it may be better to have separate drafts that describe specific policies that use this mechanism to support scenarios such as moving between UA(s).
NAME and NAME - please review and comment.
LGTM, but I'll wait until others have commented before merging.
This works for me.
Change:
false <del> When set to true, this property requests the network layer at the sending endpoint to not fragment the packets generated by the transport layer.  When running over IPv4, setting this property to true will also cause the Don't Fragment bit to be set in the IP header.  When this property is set, an attempt to send a message size </del> <ins> When set to true, this property requests the transport layer to not provide segmentation of messages larger than the maximum size permitted by the network layer, and also to avoid network-layer source fragmentation of messages.  When running over IPv4, setting this property to true can result in a sending endpount setting the Don't Fragment bit in the IPv4 header of packets generated by the transport layer.  An attempt to send a message that results in a size </ins> greater than the transport's current estimate of its maximum packet size (singularTransmissionMsgMaxLen) will result in a SendError. This only takes effect when the transport and network layer support

Discussion:
This attempts to clarify transport segmentation (a sparate PR will propose to clarify Frag)
Closing Set part of the Frag story