jiebi/CodeConvo huggingface dataset:
Change:
"ECHConfigContents.cipher_suites" list. The HPKE encapsulated key, used by servers to decrypt the <del> corresponding "payload" field. </del> <ins> corresponding "payload" field.  This field is empty in ClientHelloOuters sent in response to HelloRetryRequest. </ins> The serialized and encrypted ClientHelloInner structure, encrypted using HPKE as described in real-ech.

Discussion:
The second ClientHello after HelloRetryRequest reuses the HPKE context and calls Seal/Open a second time. To avoid needing to unnecessarily retain the enc value, and discourage servers from mistakenly recreating the HPKE context, we made it use the empty string but forgot to update the syntax to match.
Change:
On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST <del> however wait until the ACK-FREQUENCY frame that carries this new </del> <ins> however wait until the ACK_FREQUENCY frame that carries this new </ins> value is acknowledged by the peer. Until the frame is acknowledged, the endpoint MUST use the greater of

Discussion:
Also rename ACK-FREQUENCY to ACK_FREQUENCY to
Use instead of following naming convention in the transport draft.
Change:
7.3.2. This method is indicated by "jws" in the "proof" field.  A JWS <del> RFC7515 signature object is created as follows: </del> <ins> RFC7515 object is created as follows: </ins> <del> The header of the JWS MUST contain the "kid" field of the key bound to this client instance for this request.  The JWS header MUST contain an "alg" field appropriate for the key identified by "kid" and MUST NOT be "none". </del> <ins> The JOSE header MUST contain the "kid" parameter of the key bound to this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none". </ins> To protect the request, the JWS header MUST contain the following <del> additional fields. </del> <ins> additional parameters. </ins> The HTTP Method used to make this request, as an uppercase ASCII string.

Discussion:
These changes replace with replace with replace with in Detached JWS and Attached JWS sections.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit df67d81f6aadce526a2eecb1d9185d684f17242c https://deploy-preview-207--gnap-core-protocol-editors-URL
I think the proposal in could have some impact on this language, as well as making sure both attached and detached JWS methods are fully aligned.
could definitely have some impact. Although, these changes touch only the used terminology.
Accept to align with JOSE terminology, will probably be updated again when crypto methods get updated.
Change:
The SDP for |offer-B1| looks like: <del> The SDP for |candidate-B1| looks like: </del> <ins> The SDP for |offer-B1-candidate-1| looks like: </ins> <del> The SDP for |candidate-B2| looks like: </del> <ins> The SDP for |offer-B1-candidate-2| looks like: </ins> The SDP for |answer-B1| looks like: <del> The SDP for |candidate-B3| looks like: </del> <ins> The SDP for |answer-B1-candidate-1| looks like: </ins> <del> The SDP for |candidate-B4| looks like: </del> <ins> The SDP for |answer-B1-candidate-2| looks like: </ins> The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate

Discussion:
a=rtcp-mux-only LS groups
Relevant to , although there are a few nits remaining which will be handled in a followup PR
FWIW, this is atop
Added machine-filling of candidate artwork tags as well in this PR.
Follow new rules for a=rtcp, duplication of attributes Add dtls-id, rtcp-mux-only Maybe add imageattr
adds dtls-id, and I think follows the new rules for a=rtcp and attrib duplication. It doesn't yet handle the second example or do rtcp-mux-only.
Fixed by
Change:
See NSTMessage for the use of the max_early_data_size field. The parameters for the 0-RTT data (symmetric cipher suite, ALPN <del> protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del> <ins> protocol, etc.) are those associated with the PSK in use.  For externally established PSKs, the associated values are those provisioned along with the key.  For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by

Discussion:
Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment.
NAME ping? It would be good to get some resolution in this space, as it's somewhat relevant to URL
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are.
NAME is there a path forward for this (e.g., does it need to go to the list)?
NAME I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another. What say we land this without those pieces and then when we we will know what to do
SGTM. Do you need me to adjust the patch?
Nah, I'll do it.
These actually just seem to make the SNI requirements clearer but no sharper, so merging.
The Early Data Indication section contains this sentence: The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK. This implies to me that you can only do 0-RTT where the PSK was established via an earlier connection. In external PSK this is not the case. I don't think this interpretation was the intention.
This is stale text from before we allowed 0-RTT with external PSK, IIRC.
Zero-RTT Data says: But 4.6.1. New Session Ticket Message says: For consistency, I would like to have the latter in Section 2.2 with the same style. Moreover, I would like to know where this differences of requirements come from.
I think 4.2.10 may be more appropriate than 2.2, as it is closer to where the server is doing the relevant processing.
Now 4.2.10 has clear requirements. So, why don't we remove the same requirement from 2.3? additional information MUST be provisioned to both parties:
Change:
interception and possible manipulation by elements within the browser such as scripts loaded within pages.  Information in the URL is exposed through browser and server logs, and can also leak to other <del> parties through HTTP "Referrer" headers. </del> <ins> parties through HTTP "Referer" headers. </ins> GNAP's design limits the information passed directly through the browser, allowing for opaque URLs in most circumstances.  For the

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
Coverage on Sending", "Required Minimum Corruption Protection Coverage for Receiving", and "Full Checksum Coverage on Receiving". <del> 10.5. </del> <ins> 10.4. </ins> Connectedness: Connectionless

Discussion:
So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!
Change:
interface <del> Set (Preference, Enumeration) </del> <ins> Collection of (Preference, Enumeration) </ins> <del> Empty set (not setting a preference for any interface) </del> <ins> Empty (not setting a preference for any interface) </ins> This property allows the application to select any specific network interfaces or categories of interfaces it wants to "Require",

Discussion:
I should have said: I approve this, modulo the changes requested by NAME
Thanks for incorporating my suggested changes. I think this can be merged now.
Change:
position to mount these attacks, however, could achieve the same effects more easily without attacking EKT. <ins> The key encryption keys distributed with EKTKey messages are group shared symmetric keys, which means they do not provide protection within the group.  Group members can impersonate each other; for example, any group member can generate an EKT tag for any SSRC.  The entity that distributes EKTKeys can decrypt any keys distributed using EKT, and thus any media protected with those keys. </ins> Each EKT cipher specifies a value T that is the maximum number of times a given key can be used.  An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey.  In

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. <del> If the Identifier Type is 0x00 or 0x01, PATH_ABANDON frames MAY be sent on any path, not only the path identified by the Path Identifier Content field.  If the Identifier Type if 0x02, the PATH_ABANDON frame MUST only be sent on the path that is intended to be abandoned. </del> <ins> PATH_ABANDON frames MAY be sent on any path, not only the path identified by the Packet Number Space Identifier. </ins> 12.2.

Discussion:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
From PR by NAME
Looks good to me
Change:
How and if clocks are synchronized depends upon the model. <ins> In the figures below, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. </ins> 16.1. The following example illustrates a hypothetical Passport Model

Discussion:
Maybe move this paragraph to the super-section? Maybe this is intentional due to the proximity to a syntax example? Yet, the suffix syntax style is not placed here, correspondingly.
Change:
WT_DATAGRAM frames contain the following fields: <del> Length: A variable-length integer specifying the length of the Datagram Data in bytes.  Note that empty (i.e., zero-length) datagrams are allowed. Datagram Data: The content of the datagram to be delivered. </del> <ins> The content of the datagram to be delivered. </ins> The data in WT_DATAGRAM frames is not subject to flow control.  The receiver MAY discard this data if it does not have sufficient space

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
13.2. <ins> A new key type is defined for Octet Key Pairs (OKP).  Do not assume that keys using this type are elliptic curves.  This key type could be used for other curve types (for example mathematics based on hyper-elliptic surfaces). The key parameters defined in this section are summarized in table- ec1-keys.  The members that are defined for this key type are: contains an identifier of the curve to be used with the key. [CREF2] The curves defined in this document for this key type can be found in table-ec-curves.  Other curves may be registered in the future and private curves can be used as well. contains the x coordinate for the EC point.  The octet string represents a little-endian encoding of x. contains the private key. For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure.  For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure.  For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space. 13.3. </ins> Occasionally it is required that a symmetric key be transported between entities.  This key structure allows for that to happen.

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
The TokenRequest contains a supported token_type. <del> The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. </del> <ins> The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of a Public Key owned by the issuer. </ins> The TokenRequest.blinded_msg is of the correct size.

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
RFC1996 referred to this as a "master", the current common usage has shifted to "primary". <del> See primary server. </del> "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR".  (Quoted from RFC1996, Section 2.1). RFC2136 defines "primary master" as "Master server at the root of

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
(RFC6265) MAY be split into separate field lines, each with one or more cookie-pairs, before compression.  If a decompressed field section contains multiple cookie field lines, these MUST be <del> concatenated into a single octet string using the two-octet delimiter </del> <ins> concatenated into a single byte string using the two-byte delimiter </ins> of 0x3b, 0x20 (the ASCII string "; ") before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application.

Discussion:
Maybe leftovers from , or newly added text.
I'm sure the document was touched by his noodly appendage of the Octocat :octocat:
How did those slip through!?Yes, I think these are mostly new / imported from other docs.Thanks, NAME !
Change:
1. <del> In many environments, users need to connect to a captive-portal </del> <ins> In many environments, users need to connect to a captive portal </ins> device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality

Discussion:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)
Change:
Changes MUST NOT be silently ignored. The following elements of the SDP media description MUST NOT be <del> changed between the createOffer and the setLocalDescription, since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del> <ins> changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.

Discussion:
Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM
Change:
for each member of the first object with name "n" and value "v", there is a member of the second object with name "n" <del> and value "w" where "v" and "w" yield true when comparsed </del> <ins> and value "w" where "v" and "w" yield true when compared </ins> using "==", and for each member of the second object with name "n" and value "v", there is a member of the first object with name "n" and <del> value "w" where "v" and "w" yield true when comparsed using </del> <ins> value "w" where "v" and "w" yield true when compared using </ins> "==". a comparison using the operator "!=" yields true if and only if

Discussion:
Fix some nits pointed out by NAME Improve definition of children Unicode Scalar Values are integers Typo fix Ordering of non-integer numbers
Change:
(2) The client instance request. (3) The AS processes the request and determines what is needed to <del> fulfill the request.  The AS sends its response. </del> <ins> fulfill the request.  (See authorization.)  The AS sends its response. </ins> (B) If interaction is required, the AS authorization to gather authorization.  The interactive component of the AS can function

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 88c9fdd493cc1d969e1405501ff6b7d071b218e9 Inspect the deploy log: Browse the preview:
In section 1.4, the text states: How can the AS "determine what is needed to fulfill the request" ? Shall the AS have established some prior relationship ? If yes, what such relationships consist of ? If no, can "other means" be used ?
Change:
the captive portal operator can attempt to reassure the user that the captive portal is not malicious. <ins> Each of the options described in this document is presented to a node using the same protocols used to provision other information critical to the node's successful configuration on a network.  The security considerations applicable to each of these provisioning mechanisms also apply when the node is attempting to learn the information conveyed in these options.  In the absence of security measures like RA Guard (RFC6105, RFC7113) or DHCP Shield RFC7610, an attacker could inject, modify, or block DHCP messages or RAs. </ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing.  As an attacker with this capability could <del> simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, but because this document removes the need for </del> <ins> simply list themselves as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, but because this document removes the need for </ins> interception, the attacker may have an easier time performing the <del> attack.  As the operating systems and application that make use of </del> <ins> attack. However, as the operating systems and application that make use of </ins> this information know that they are connecting to a captive-portal device (as opposed to intercepted connections) they can render the page in a sandboxed environment and take other precautions, such as

Discussion:
Thread: URL
Perhaps a reference to URL as well as the security considerations sections of 2131, 4861, 4862, and 8415.
The new paragraph is good. The other sentence is a little hard to understand and risks opening questions that we probably don't want opened. Reviewer: Rifaat Shekh-Yusef Review result: Has Issues Since the use of IP address literal is not forbidden by this document, what if an attacker with the ability to inject DHCP messages or RAs uses this option to force the user to contact an IP address of his choosing? In this case, the use of TLS and presenting the identity in the certificate might not be of much help. I think this case should be discussed in the security consideration section.
Change:
In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits <del> using the "rate-limit" relation. </del> <ins> using the "urn:ietf:params:acme:documentation" relation. </ins> 5.7.

Discussion:
As they are all fulfilled by the endpoint and are unnecessary. The relation is removed as the SCT will be provided by the CA via the certificate or a OCSP response, if it doesn't provide these then the client should be able to retrieve the SCT itself from the logs it expects to find the certificate in (or submit it itself). Also removes a paragraph about Certificate Transparency from the 'Downloading the Certificate' section as it is irrelevant to the section and discusses operations of the CA unrelated to the ACME protocol. Additionally changes the relation which is not registered with a URI extension using the ACME URN namespace .
Looks good. Was posted on the list two weeks ago, with no objections, so merging.