jiebi/CodeConvo huggingface dataset:
Change:
When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including <del> unreliable delivery; see format.  Negotiation is achieved using a setting; see setting. </del> <ins> unreliable delivery; see format.  Negotiating the use of QUIC DATAGRAM frames for HTTP Datagrams is achieved via the exchange of HTTP/3 settings; see setting. </ins> When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP

Discussion:
Using a slight variation of David's proposed text on the issue.
In Section 2: "Negotiation is achieved using a setting; see Section 2.1.1." So first I though this was just lacking an "HTTP" prior to the setting. But, I think this glosses over the general negotiation complications across versions. In this section when the high level functionality is defined, I think actually the question of negotiation in general needs to be discussed, not only for HTTP/3.
I don't understand this issue, could you elaborate? I'm assuming you are talking about Section 2 para 2, which says: The remaining paragraphs deal with consideration of other versions, and mention negotiation.
I think we can improve clarity here. Right now we have in the "HTTP Datagrams" section. We should spell it out better, maybe:
WFM
Change:
Implementations MAY include the length field at their discretion. The entire header value shown above is used as it appears on the wire <del> as the additional data value for the AEAD function. </del> <ins> as the additional data value for the AEAD function.  Note that this design is different to the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. </ins> 4.1.

Discussion:
I added this remark following my implementation experience of DTLS 1.2 CID followed by the work on the DTLS 1.3. We noticed this issue at the Prague IETF meeting (March 2019).
Change:
HTTP: Provision files under .well-known on a web server for the domain <del> TLS SNI: Configure a TLS server for the domain </del> DNS: Provision DNS resource records for the domain There are several ways that these assumptions can be violated, both by misconfiguration and by attacks.  For example, on a web server that allows non-administrative users to write to .well-known, any user can claim to own the web server's hostname by responding to an <del> HTTP challenge, and likewise for TLS configuration and TLS SNI. Similarly, if a server that can be used for ACME validation is compromised by a malicious actor, then that malicious actor can use that access to obtain certificates via ACME. </del> <ins> HTTP challenge.  Similarly, if a server that can be used for ACME validation is compromised by a malicious actor, then that malicious actor can use that access to obtain certificates via ACME. </ins> The use of hosting providers is a particular risk for ACME validation.  If the owner of the domain has outsourced operation of

Discussion:
Recent developments[[0]] [[1]] [[2]] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 and its currently specified replacement, TLS-SNI-02. In light of these issues and the feasibility of addressing them across the entire Internet it seems prudent that the ACME specification remove the affected challenge type pending the development of a better alternative (TLS-SNI-03?). This will allow the draft last-call to proceed while the details of TLS-SNI-03 are worked out. The "Default Virtual Hosts" sub-section of the "Operational Considerations" section is removed since it spoke exclusively to a concern with TLS-SNI-02 validation. When the dust has settled on TLS-SNI-03 we should certainly include a section that describes why TLS-SNI-01/02 were removed that could replace this information. [0]: URL [1]: URL [2]: URL
NAME I don't think we need a place-holder in-doc for this
r+ with the one comment addressedShould there be any mention of that makes sure we use in a future RFC in case if gets re-added?
Change:
10.1. <del> The Connection Properties defined as independent of the chosen protocol stack, and available on all Connections are defined in the subsections below. </del> <ins> Generic Connection Properties are defined independent of the chosen protocol stack and therefore available on all Connections. </ins> Note that many Connection Properties have a corresponding Selection <del> Property, which enables applications to express their preference for </del> <ins> Property which enables applications to express their preference for </ins> protocols providing a supporting transport feature. 10.1.1.

Discussion:
Comma in the first section was wrong but better to rephrase anyway...
nit
Change:
The endpoint then finds one or more addresses of the directory server as described in simple_finding. <del> An endpoint can send (a selection of) hosted resources to a directory server for publication as described in simple_publishing. </del> <ins> An endpoint finally asks the directory server to probe it for resources and publish them as described in simple_publishing. </ins> The directory server integrates the information it received this way into its resource directory.  It MAY make the information available

Discussion:
Some minor text changes (commented per commit) I think are resonable and will merge soon unless someone speaks up against them.
Change:
This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the congestion controller.  For example, a pacer might distribute the <del> congestion window over the SRTT when used with a window-based </del> <ins> congestion window over the smoothed RTT when used with a window-based </ins> controller, and a pacer might use the rate estimate of a rate-based controller.

Discussion:
In section "Time Threshold", is used for the first time. I guess that would reference the same value before called ? If that's the case they should be named the same. Further down in the same paragraph "smoothed SRTT" is used which is even more confusing. SRTT is used a few more times further down.
There was a cleanup a while ago to ensure definitions such as SRTT happened before use, but that might have been lost in recovery to transport migration?
:+1:
Change:
The typical interaction flow for Privacy Pass uses the following steps: <del> A Client interacts with an Origin by sending an HTTP request.  The Origin sends an HTTP response that contains a token challenge that indicates a specific Issuer to use.  Note that the request might be made as part of accessing a resource normally, or with the specific intent of triggering a token challenge. </del> <ins> A Client interacts with an Origin by sending a request or otherwise interacting with the Origin in a way that triggers a response containing a token challenge.  The token challenge indicates a specific Issuer to use. </ins> If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of

Discussion:
The interaction model here doesn't really need to use HTTP as far as I can tell. Obviously, the specific protocols need to be more concrete, but the architecture works without specifically saying that the interactions use HTTP. The overview specifically mentions HTTP only with respect to the Client-Origin interactions, not other interactions, but I can't see how this is necessary.
No, it doesn't need to use HTTP. The auth scheme document that instantiates the challenges and redemption does use HTTP, but other mechanisms can be used.
I'm OK de-emphasizing HTTP in the architecture if it helps simplify the presentation. Beyond it overly restrictive, was there another reason that led to this issue, NAME
Only that I know that this has obvious applications beyond HTTP and the architecture has no direct need to use it.
Request/response is still a bit implying HTTP, but I'm OK with this change.
Change:
Every FIDO Authenticator contains an Attester. <del> Any web site, mobile application back end or service that does biometric authentication. </del> <ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information. </ins> 3.

Discussion:
` It sounds like the Verifier “does” the authentication, and the relying party relies on the answer?
Besides, there's a slight imprecision here: the web site / mobile app backend service don't do biometric auth. Instead, the authenticator binds biometric info to crypto material so that the web site can deal with usual crypto auth.
For context, this is https://ietf-rats-URL How about:
Change:
different from the one used to receive it, as the request encoding differs by version (see below). <del> otherwise, the recipient will act as an IP proxy.  It extracts the optional "target" and "ipproto" variables from the URI it has reconstructed from the request headers, decodes their percent- encoding, and establishes an IP tunnel. </del> <ins> otherwise, the recipient will act as an IP proxy.  The IP proxy can choose to reject the IP proxying request.  Otherwise, it extracts the optional "target" and "ipproto" variables from the URI it has reconstructed from the request headers, decodes their percent-encoding, and establishes an IP tunnel. </ins> IP proxies MUST validate whether the decoded "target" and "ipproto" variables meet the requirements in scope.  If they do not, the IP proxy MUST treat the request as malformed; see H2 and H3.  If the "target" variable is a DNS name, the IP proxy MUST perform DNS <del> resolution before replying to the HTTP request.  If errors occur during this process, the IP proxy MUST reject the request and SHOULD send details using an appropriate Proxy-Status header field PROXY- STATUS.  For example, if DNS resolution returns an error, the proxy can use the "dns_error" Proxy Error Type from PROXY-STATUS. </del> <ins> resolution (to query the corresponding IPv4 and/or IPv6 addresses via A and/or AAAA records) before replying to the HTTP request.  If errors occur during this process, the IP proxy MUST reject the request and SHOULD send details using an appropriate Proxy-Status header field PROXY-STATUS.  For example, if DNS resolution returns an error, the proxy can use the "dns_error" Proxy Error Type from PROXY- STATUS. </ins> The lifetime of the IP forwarding tunnel is tied to the IP proxying request stream.  The IP proxy MUST maintain all IP address and route

Discussion:
This is an editorial PR based on comments made by Chris Wood during his shepherd review of the document.
Change:
[[OPEN ISSUE: The threat model for Prio -- as it's described in the original paper and BBCGGI19 -- considers <del> a malicious client (attacking soundness) </del> <ins> a malicious client (attacking robustness) </ins> a malicious subset of aggregators (attacking privacy).  In <del> particular, soundness isn't guaranteed if any one of the aggregators </del> <ins> particular, robustness isn't guaranteed if any one of the aggregators </ins> is malicious; in theory it may be possible for a malicious client and <del> aggregator to collude and break soundness.  Is this a contingency we </del> <ins> aggregator to collude and break robustness.  Is this a contingency we </ins> need to address?  There are techniques in BBCGGI19 that account for this; we need to figure out if they're practical.]]

Discussion:
NAME let's squash-then-merge this change.
contains a nice definition and discussion of the notions of privacy (meaning protecting any individual client's measurement from being seen) and robustness (meaning that the aggregates delivered to a collector are accurate aggregations over the inputs). DAP's security considerations has definitions of privacy and correctness, and we refer to robustness and soundness in a few places. We should align our definitions with VDAF (or just refer to VDAF's definitions) and consistently use the term "robustness" throughout DAP.
PR, please!
I'm going to get this done for draft-02, hopefully early next week.
Change:
4.3.2. In the dynamic allocation method, the load balancer assigns server <del> IDs dynamically so that configuration does not require bespoke server ID assignment.  This also reduces linkability.  However, it requires state at the load balancer that roughly scales with the number of </del> <ins> IDs dynamically so that configuration does not require fixed server ID assignment.  This reduces linkability.  However, it requires state at the load balancer that roughly scales with the number of </ins> connections, until the server ID codespace is exhausted. 4.3.2.1.

Discussion:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Change:
path is unusable.  This does not necessarily imply a failure of the connection - endpoints can continue sending packets over other paths as appropriate.  If no paths are available, an endpoint can wait for <del> a new path to become available or close the connection. </del> <ins> a new path to become available or close the connection.  An endpoint that has no valid network path to its peer MAY signal this using the NO_VIABLE_PATH connection error, noting that this is only possible if the network path exists but does not support the required MTU datagram-size. </ins> A path validation might be abandoned for other reasons besides failure.  Primarily, this happens if a connection migration to a new

Discussion:
This is a bit of a niche code, as it is only narrowly useful for signaling loss of paths. But people wanted it and it doesn't code that much. Note the target of this pull request. For .
I'm going to leave this for a bit, but if people like the idea, I plan to merge it into .
Thank you for the PR. This error code will be useful, as the only other way of closing the connection would be to use NO_ERROR. Then, it would be impossible to know why the connection was abruptly closed.Yes, there's value in having a way to fail URL suggestion, but lgtm
Change:
In TLS 1.3, the server sends the "record_size_limit" extension in the EncryptedExtensions message. <ins> 4.1. The size limit expressed in the "record_size_limit" extension doesn't account for expansion due to compression or record protection.  It is expected that a constrained device will disable compression to avoid unpredictable increases in record size.  Stream ciphers and existing AEAD ciphers don't permit variable amounts of expansion, but block ciphers do permit variable expansion. In TLS 1.2, block ciphers allow between 1 and 256 octets of padding. When a limit lower than the protocol-defined limit is advertised, a second limit applies to the length of records that use block ciphers. An endpoint MUST NOT add padding to records that would cause the protected record to exceed the size of a protected record that contains the maximum amount of plaintext and the minimum permitted amount of padding. For example, TLS_RSA_WITH_AES_128_CBC_SHA has 16 octet blocks and a 20 octet MAC.  Given a record size limit of 256, a record of that length would require a minimum of 11 octets of padding (for RFC5246 where the MAC is covered by encryption); or 15 octets if the "encrypt_then_mac" extension RFC7366 is negotiated.  With this limit, a record with 250 octets of plaintext could be padded to the same length by including at most 17 octets of padding; or 21 octets with "encrypt_then_mac". An implementation that always adds the minimum amount of padding will always comply with this requirement. </ins> 5. The "record_size_limit" extension replaces the "max_fragment_length"

Discussion:
The idea of this change is to try to constrain how much padding a sender can add. This is done by calculating the size of a record with maximum plaintext and minimum padding. No other record can exceed this size, though smaller packets can pad to reach this size. I was going to include a formula, then realized that the simple answer is best: pad to the record size limit, then pad to get to a multiple of the block size as normal. Most implementations will be OK because they don't bother with the first step.
Change:
allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). <del> An optional field for binding the new account with an existing non-ACME account (see external-account-binding ). </del> <ins> Same meaning as the corresponding server field defined in </ins> The server MUST ignore any values provided in the "orders" fields in <del> account bodies sent by the client, as well as any other fields that </del> <ins> account objects sent by the client, as well as any other fields that </ins> it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be <del> provided by the client. In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </del> <ins> provided by the client.  The server MUST NOT reflect the "onlyReturnExisting" field or any unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </ins> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the server validates

Discussion:
From Section 7.3: "MUST URL account bodies sent by the URL other fields that it does not recognize" in the first paragraph seems to be unnecessarily repeated by "MUST ignore any fields in the request object that it does not recognize" in the second paragraph. This PR merges these two paragraphs and discards the duplicated text. Also, "account bodies" isn't used anywhere else in the document, so this PR changes it to "account objects".
This looks reasonable to handle in AUTH48.
the last part isn't purely editorial, but okay.
Change:
by matching KeyConfig.key_id, or, if the Target Resource is willing to use trial decryption, a limited set of key configurations that share an identifier.  An Oblivious Relay Resource can link requests <del> using the public key corresponding to KeyConfig.key_id. Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. Specifically, servers can maliciously construct key configurations to track individual clients.  A specific method for a client to acquire key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations to mitigate tracking using key configurations.  CONSISTENCY provides an analysis of the options for ensuring the key configurations are consistent between different clients. </del> <ins> using the public key corresponding to KeyConfig.key_id or via the URI of the Oblivious Gateway Resource.  We refer to this set of information as the gateway's configuration. Whether or not targets can link requests depends on how gateway configuration information is produced and discovered by clients. Specifically, gateways can maliciously construct configurations to track individual clients. Ideally, all clients share a consistent view of the gateway configuration.  The number of different valid configurations can exponentially partition the anonymity set of clients.  For example, if there are two valid configurations, that would yield two anonymity sets consisting of clients that used one configuration and clients that used the other configuration.  If the size of each set is large enough, this may not be a significant loss of privacy in practice. Ensuring that many clients share a configuration is necessary to provide privacy for clients. A specific method for a client to acquire configurations is not included in this specification.  Applications using this design MUST provide accommodations to mitigate tracking using gateway configurations.  CONSISTENCY provides options for ensuring that configurations are consistent between clients. </ins> 9.

Discussion:
URL a partial one. From IETF 114: I don't know if it is worth enumerating all of the combinations is viable, but we might consider talking about the exact shape of the consistency requirements here.
Change:
from the same User Equipment and return the state of captivity for the equipment. <del> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the User Portal. </del> <ins> At minimum, the API MUST provide the state of captivity.  Further the API MUST be able to provide a URI for the User Portal. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.

Discussion:
This was raise during multiple reviews: the api doesn't make the user portal URI mandatory. Further, there is a use-case where we want to notify of a 'venue url' without being captive. Change up the wording.
Tirupachur Comerica, Subash writes:
This was also brought up by Martin Duke during the the api document's last call. Let's fix it. Two options were raised during that review (by Tommy and Erik, respectively): Require that the API be able to provide the URI Qualify the requirement to indicate when the URI is required (e.g. when captive portal enforcement may be active). Some proposals: I'm not sure it's worth discussing the use-case that leads to it being useful for it to be optional (e.g. the venue w/ notification or extra info).
We went with the first proposal, "the API MUST be able to provide a URI"
The new wording leaves it open for the API to make it optional. OK.
Change:
The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names <del> where some of the right-most names are left off and are understood </del> <ins> where one or more of the earliest labels in the ordered list are omitted (for example, "www").  Such relative names are understood </ins> only by context. This term and its equivalent, "hostname", have been widely used

Discussion:
Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.