jiebi/CodeConvo huggingface dataset:
Change:
Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field.  This connection MUST be sent <del> to TCP port 443 on the server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension </del> <ins> to TCP port 443 on the TLS server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension </ins> (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
Push ID that is larger than the client has provided in a MAX_PUSH_ID frame (frame-max-push-id).  A client MUST treat receipt of a DUPLICATE_PUSH that contains a larger Push ID than the client has <del> advertised as a connection error of type HTTP_MALFORMED_FRAME. </del> <ins> advertised as a connection error of type HTTP_ID_ERROR. </ins> This frame allows the server to use the same server push in response to multiple concurrent requests.  Referencing the same server push

Discussion:
Implements suggestions from
Updated to replace HTTPLIMITEXCEEDED and HTTPPUSHIDERROR with the single error HTTPID_ERROR.
There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTPDUPLICATEPUSH with an HTTPPUSHIDERROR code, and replaces use of HTTPMALFORMED frame. Note, on I suggested a slightly different solution to replace HTTPMALFORMED FRAME, but I think this is a better path.
To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like "IDERROR, STREAMIDERROR. Also, using PUSHIDERROR in some cases while using MALFORMEDFRAME in others seems confusing. I think we might want to consider doing either of the two: Use PUSHIDERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3 Introduce IDERROR that captures all the limit and ID errors.
Thanks NAME The proposal is a bit of a compromise, so I agree with some of the points that you make. I like your idea of replacing HTTPLIMITEXCEEDED with HTTPIDERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics. What follows is the response I made first, before coming to that agreement :) Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTPLIMITEXCEEDED. Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions. However, server push is a little different because it's ID space is managed by the MAXPUSHID frame. The three errors that use HTTPPUSHIDERROR are unique to push.

However, if we modified HTTPLIMITEXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTPID_ERROR) I think that would work.
I updated the PR with the above, so that we can see what it looks like.
I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me. I suspect that means I don't actually disagree, I just need some time to wrap my head around it.
We merged so I'm closing this as completed.
Change:
this scenario in fig:rel_multi. A multicast flow (M) is forwarded to both satellite terminals A and <del> B.  However packet Ni (resp.  Nj) get lost at terminal A (resp.  B), </del> <ins> B.  However packet Ni (resp.  Nj) gets lost at terminal A (resp.  B), </ins> and terminal A (resp.  B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing.  Then either the access gateway or the multicast server includes a repair packet (rather than

Discussion:
Answer to issue
John Border: Section 4.2, 2nd Paragraph "Unidirectional" implies (to me) no ACKs. Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost. This seems different enough to me to be explained separate from NORM.
Our objective is not to discuss about NORM and FLUTE, which is out of scope of the document. We cite these protocols as possible usage example. Also note that although FLUTE is unidirectional, the RFC keeps a door open proposing bidirectional communications for security purpose and to enable full reliability transfer. As a result, we move this sentence at the end of this section as a complementary material and completed the FLUTE description.
Change:
In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header <del> section, or the response header section.  As a result, only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections. </del> <ins> section, or the response header section.  As a result, only the last HTTP request on an HTTP/1.x connection can start the capsule protocol. </ins> In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding

Discussion:
Nit from AD review: The original sentence is ambiguously worded, and could be interpreted as saying that there could not be normal HTTP requests prior to the capsule protocol.
Thanks, this is an important clarification that makes clearer the original intent of the statement.
Change:
The goals of this proposal are: <del> Standardizing the names and semantics of rate-limit headers to ease their enforcement and adoption; </del> <ins> Standardization of the names and semantics of rate-limit headers to ease their enforcement and adoption; </ins> Improve resiliency of HTTP infrastructure by providing clients with information useful to throttle their requests and prevent 4xx

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:
also provides both hop-by-hop and end-to-end security guarantees, but can be used with other transport protocols beyond SRTP. <del> If a content provider chooses not to involve intermediaries, this choice should be carefully considered.  As an example, if media manifests are encrypted end-to-end, network providers who had been able to lower offered quality and reduce on their networks will no longer be able to do that.  Some resources that might inform this consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- </del> <ins> The choice of whether to involve intermediaries sometimes requires careful consideration.  As an example, when ABR manifests were commonly sent unencrypted some networks would modify manifests during peak hours by removing high-bitrate renditions in order to prevent players from choosing those renditions, thus reducing the overall bandwidth consumed for delivering these media streams and thereby improving the network load and the user experience for their customers.  Now that ubiquitous encryption typically prevents this kind of modification, in order to maintain the same level of network health and user experience across networks whose users would have benefitted from this intervention a media streaming operator sometimes needs to choose between adding intermediaries who are authorized to change the manifests or adding significant extra complexity to their service. Some resources that might inform other similar considerations are further discussed in RFC8824 (for WebRTC) and I-D.ietf-quic- </ins> manageability (for HTTP/3 and QUIC). 7.3.

Discussion:
…seemed more well covered in 8824 than in 8825.)
IGTM!
From NAME Last paragraph, while I understand why some mobile providers wants "to lower quality" it would be easier for the reader to understand if the text said "in order to reduce the bandwidth on expensive links, some operators want to lower the quality".
Describe how editing manifests lowers the bandwidth requirements.
Change:
either image independently, as well as to update them together atomically, as specified in the associated manifests. <del> 7.3. </del> <ins> 5.3. </ins> In more complex SoCs with symmetric multi-processing support, advanced operating systems, such as Linux, are often used.  These <del> SoCs frequently use an external storage medium such as raw NAND flash or eMMC.  Due to the higher quantity of resources, these devices are often capable of storing multiple copies of their firmware images and selecting the most appropriate one to boot.  Many SoCs also support bootloaders that are capable of updating the firmware image, however this is typically a last resort because it requires the device to be held in the bootloader while the new firmware is downloaded and installed, which results in down-time for the device.  Firmware updates in this class of device are typically not done in-place. 7.4. </del> <ins> SoCs frequently use an external storage medium, such as raw NAND flash or eMMC.  Due to the higher quantity of resources, these devices are often capable of storing multiple copies of their firmware images and selecting the most appropriate one to boot.  Many SoCs also support bootloaders that are capable of updating the firmware image, however this is typically a last resort because it requires the device to be held in the bootloader while the new firmware is downloaded and installed, which results in down-time for the device.  Firmware updates in this class of device are typically not done in-place. 5.4. </ins> This configuration has two or more heterogeneous CPUs in a single SoC <del> that share memory (flash and RAM).  Generally, they will be a protection mechanism to prevent one CPU from accessing the other's memory.  Upgrades in this case will typically be done by one of the CPUs, and is similar to the single CPU with secure mode. </del> <ins> that share memory (flash and RAM).  Generally, there will be a mechanism to prevent one CPU from unintentionally accessing memory currently allocated to the other.  Upgrades in this case will typically be done by one of the CPUs, and is similar to the single CPU with secure mode. </ins> <del> 7.5. </del> <ins> 5.5. </ins> This configuration has two or more heterogeneous CPUs, each having their own memory.  There will be a communication channel between

Discussion:
First chunk of changes.
This is a really great set of edits. I think that it really improves the document as a whole! I have suggested a couple of minor edits.Quick partial language review
Change:
takes as input an arbitrary-length message, rather than a digest. Algorithms which traditionally act on a digest should be defined in TLS to first hash the input with a specified hash function and then <del> proceed as usual. </del> <ins> proceed as usual.  The code point groups listed above have the following meanings: </ins> Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC3447

Discussion:
The definition is all "etcetera" currently. We should not assume that readers can parse out the hash algorithm from the enum label.
Change:
A push service that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application <del> server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. </del> <ins> server, incurring additional power drain in order to establish and maintain (usually secure) connections to the individual application servers. </ins> Push message reliability can be important if messages contain information critical to the state of an application.  Repairing state

Discussion:
This is the initial update for the Spencer Dawkins review. I'll wait to see if there are additional comments to address before merging. Editorial update to Section 7.4 Also fixed a the a nit.
Merging per Spencer's response.
Change:
unauthorized. Except for the directory resource, all ACME resources are addressed <del> with URLs provided to the client by the server.  In requests sent to these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter.  The server MUST reject the request as unauthorized if the string equality check fails. </del> <ins> with URLs provided to the client by the server.  In POST requests sent to these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. The server MUST reject the request as unauthorized if the string equality check fails. </ins> 6.4.1.

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
application to supply a "reference identifier" for the authenticated client, if any. <del> A BasicCredential is a bare assertion of an identity, without any </del> <ins> A "basic" credential is a bare assertion of an identity, without any </ins> additional information.  The format of the encoded identity is defined by the application.

Discussion:
made me realize that BasicCredential actually doesn't exist anymore!
Well, "basic" is listed as a credential type in the IANA registry defined in . That said, your proposed text seems perfectly consistent with the registry and the rest of the document.
Change:
certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST <del> NOT proceed with any of the behavior described above. </del> <ins> NOT make any calls to the API server. </ins> 2.2. Here we discuss candidate mechanisms for provisioning the User <del> Equipment with the URI of the API to query captive portal state and navigate the portal. </del> <ins> Equipment with the Captive Portal API URI to query captive portal state and navigate the portal. </ins> 2.2.1. <del> A standard for providing a portal URI using DHCP or Router Advertisements is described in RFC7710bis.  The captive portal </del> <ins> A standard for providing a Captive Portal API URI using DHCP or Router Advertisements is described in RFC7710bis.  The captive portal </ins> architecture expects this URI to indicate the API described in section_api.

Discussion:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.
Change:
Structure of this message: %%% Authentication Messages struct { digitally-signed struct { opaque <del> handshake_hash[hash_length]; } } CertificateVerify; </del> <ins> handshake_hash[hash_length]; }; } CertificateVerify; </ins> Where session_hash is as described in the-handshake-hash and includes the messages sent or received, starting at ClientHello

Discussion:
Missing semi-colon in the message definition. Also, the signature_algorithms of the client are what matter.
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.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve performance. </del> <ins> next protocol.  To improve performance, implementations SHOULD ensure that there is a way to pass the original data through without copying. </ins> To provide an example, a simple protocol that adds a length as a header would receive the "NewSentMessage" event, create a data

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
parameters for the incoming request match those that it is expecting from the session created in (1).  The client instance also needs to be prepared for the end-user never being returned to <del> the client instance and handle time outs appropriately. </del> <ins> the client instance and handle timeouts appropriately. </ins> The client instance loads the continuation information from (3) and sends the interaction reference from (7) in a request to

Discussion:
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fd1d0f88ac7d2a9ad6f43bb6d959a2aa84558f2b https://deploy-preview-179--gnap-core-protocol-editors-URL
One small change needed (marked) but otherwise good!
Change:
session. This document. <ins> In addition, the following range of entries is registered: H3_WEBTRANSPORT_APPLICATION_00 ... H3_WEBTRANSPORT_APPLICATION_FF 0x52e4a40fa8db to 0x52e4a40fa9e2 inclusive, with the exception of 0x52e4a40fa8f9, 0x52e4a40fa918, 0x52e4a40fa937, 0x52e4a40fa956, 0x52e4a40fa975, 0x52e4a40fa994, 0x52e4a40fa9b3, and 0x52e4a40fa9d2. WebTransport application error codes. This document. 7.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </ins>

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:
6.1. <ins> For protocols that employ request/response pairs and do not require in-order delivery of the responses, like HTTP, the transport implementation may distribute interactions across several underlying transport connections.  For these kinds of protocols, implementations may hide the connection management and only expose a single Connection object and the individual requests/responses as messages. These Pooled Connections can use multiple connections or multiple streams of multi-streaming connections between endpoints, as long as all of these satisfy the requirements, and prohibitions specified in the Selection Properties of the Pooled Connection.  This enables implementations to realize transparent connection coalescing, connection migration, and to perform per-message endpoint and path selection by choosing among these underlying connections. 6.2. </ins> When a path change occurs, the Transport Services implementation is responsible for notifying Protocol Instances in the Protocol Stack. If the Protocol Stack includes a transport protocol that supports

Discussion:
This is a follow-up issue for – As we have the ready to support connection coalescing and connection pooling, we have to describe it more closely in the Implementation.
Thanks for the fixes - I think this can be merged now.LGTM And: thanks for doing this! This can make the transport system a lot more powerful, and it's good to tell people about these interesting implementation options this draft, IMO.
Change:
encode 6, 14, 30, or 62 bit values respectively.  integer-summary summarizes the encoding properties. <del> For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). </del> <ins> Examples and a sample decoding algorithm are shown in sample-varint. </ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding.

Discussion:
if we decide we need/want it.
And yes, this handwaves over coercing the mask into the right size integer for the number of bytes you read.
When you do that, it's probably worth copying the "Code Components" language from -recovery.
hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). The Some hex & decimal indication would help. A picture is worth a thousand words and save the reader drawing this out themselves to understand it and getting confused. The conversion pseudo code would be helpful, possibly in an appendix.
I don't think that any change is needed here. It says "in hexadecimal" and "decimal value" right there.
We could put comma separators in the decimal values (i.e. 494878333 => 494,878,333) so they're more readily parsed as decimals rather than digit sequences. And an appendix with a varint decoder might not be the worst idea.