jiebi/CodeConvo huggingface dataset:
Change:
"batch_interval", the request's batch interval. "agg_param", an aggregation parameter for the VDAF being executed. <ins> This is the same value as in "AggregateInitializeReq" (see leader- init). </ins> Depending on the VDAF scheme and how the leader is configured, the leader and helper may already have prepared all the reports falling

Discussion:
Similar to , it should not be possible for a share to be included in more than one batch. The timestamp currently gives us some way of ensuring that reports map to at most batch, but not a way of ensuring that reports aren't included two overlapping batch windows. It's not immediately clear if include a single report in two overlapping batch windows is a problem, or if a problem only arises when these windows are disjoint. We should probably clarify what are the inter-batch requirements here and what sort of replay prevention is required.
The aggregators (either the leader or helper) can prevent the collector from getting outputs from overlapping batches by remembering batch intervals. For example, suppose the leader responded successfully to a collect request for time interval . Then suppose that, some time later, the collector requests output shares for , where . The potential privacy violation occurs because the sets of reports in each batch are non-disjoint. To prevent this, the leader might respond to the second request with an error, or it might just include the reports in .
If aggregators are meant to use the report timestamp to protect against replay, then I think it needs to appear in the AEAD-ed message constructed by the client (i.e. ). Otherwise a leader could insert arbitrary timestamps into and trick helpers into exceeding privacy budgets or double counting inputs. Additionally, a batching client could insert arbitrary values into .
I created a PR that addresses this issue partially. What's left to do is allow multiple collect requests over the same batch, as required by the PDA protocol (e.g., Hits). I have an idea for how to do this, I'll follow up with a PR.
Closed by URL
LGTM -- thanks!
Change:
11.17. The mtls provides a means for a client instance to present a key <del> using a certificate the TLS layer.  Since TLS protects the entire </del> <ins> using a certificate at the TLS layer.  Since TLS protects the entire </ins> HTTP message in transit, verification of the TLS client certificate presented with the message provides a sufficient binding between the two.  However, since TLS is functioning at a separate layer from

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:
1. <del> The Web Push protocol I-D.ietf-webpush-protocol describes how an application server is able to request that a push service deliver a push message to a user agent. </del> <ins> The Web Push protocol RFC8030 describes how an application server is able to request that a push service deliver a push message to a user agent. </ins> As a consequence of the expected deployment architecture, there is no basis for an application server to be known to a push service prior

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
This document <del> 9.2. An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 10.  References </del> <ins> 11.  References </ins> <del> 10.1.  URIs </del> <ins> 11.1.  URIs </ins> [1] mailto:webtransport@ietf.org

Discussion:
There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.
Change:
and encrypting large parts of the TLS handshake including the certificate messages. <del> EAP-TLS peer and server implementations supporting TLS 1.3 or higher MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in RFC7542) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response.  Following RFC7542, it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g., </del> <ins> EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in RFC7542) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response.  Following RFC7542, it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g., </ins> xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of RFC7542.

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
2.3. <ins> Applications that have a mapping for TCP as well as QUIC are expected to use the same port number for both services.  However, as with TCP- based services, especially when application layer information is encrypted, there is no guarantee that a specific application will use the registered port, or the used port is carrying traffic belonging to the respective registered service.  For example, QUIC-TRANSPORT specifies the use of Alt-Svc for discovery of QUIC/HTTP services on other ports. Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the connection ID is not present in the packet header, all packets of the 5-tuple belong to the same QUIC connection. 2.4. </ins> New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed.

Discussion:
also to address issue
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Change:
For example, suppose there is a group with four members: If member B subsequently generates a Commit based on a secret <del> "leaf_hpke_secret", then it would generate the following sequence of path secrets: </del> <ins> "leaf_secret", then it would generate the following sequence of path secrets: </ins> After the Commit, the tree will have the following structure, where "np[i]" represents the node_priv values generated as described above: <ins> After performing these operations, the generator of the Commit MUST delete the leaf_secret. </ins> 5.5. The members of the group need to keep their views of the tree in sync

Discussion:
This PR tries to clarify these paragraphs by the following: Differentiating between HPKE public/private keys when describing how these keys are rotated for a commit Clarifying who does the actions associated with a commit Adding consistency fixes between the two paragraphs Let me know if these fixes are not quite right, as this PR tries to clarify where I had questions when reading.
Change:
(*) indicates changes to the wire protocol. <del> draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  * Additional security considerations. </del> <ins> draft-05 Removed support for PKCS 1.5 RSA signature algorithms. Additional security considerations. </ins> draft-04

Discussion:
Fix formatting issue in changes.
This is trivial and straightforward change so I'm just going to merge this directly.
Change:
Static vectors (see static-vectors): "Extension.extension_data" for any extension in <del> "expected_extensions" whose value has fixed length.  This applies only to the corresponding message. </del> <ins> "expected_extensions" whose value is self-delimiting (e.g., fixed length).  This applies only to the corresponding message. </ins> The "extensions" field of the corresponding message, if "allow_additional" is false.

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
5. It is important to this solution framework that the entities can <del> trust and validate the authenticity of other entities, especially the Key Distributor and endpoints.  The details of this are outside the scope of specification but a few possibilities are discussed in the </del> <ins> validate the authenticity of other entities, especially the Key Distributor and endpoints.  The details of this are outside the scope of specification but a few possibilities are discussed in the </ins> following sections.  The key requirements is that endpoints can verify they are connected to the correct Key Distributor for the conference and the Key Distributor can verify the endpoints are the

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.
Change:
alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure. <del> 5.12. </del> <ins> 5.11. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is

Discussion:
This makes the handshake the same as TLS 1.3 (modulo the version numbers, which are conveniently different.
As discussed at the meeting. NAME PTAL.
This also LGTM. Let's do a brief consensus call before merging.
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document defines requirements on future QUIC versions, even where normative language is not used. </ins> This document uses terms and notational conventions from QUIC- TRANSPORT.

Discussion:
This is right next to the BCP 14 text. (Based on private conversation with Joel Halpern who expressed the concern that this seems to lack overt normative force.)
Change:
requests without an entity body are not authenticated, in particular GET requests.  Except for the cases described in this section, if the server receives a GET request, it MUST return an error with status <del> code 405 "Method Not Allowed" and type "malformedRequest". </del> <ins> code 405 "Method Not Allowed" and type "malformed". </ins> If a client wishes to fetch a resource from the server (which would otherwise be done with a GET), then it MUST send a POST request with

Discussion:
As suggested by David Hancock, change the certificate fetch examples to use POST-as-GET, noting that GET is optional As suggested by Felix Fontein, use the correct error code for "malformed" in the description of what servers should do in response to inappropriate GET requests
Since doesn't look like it will be merged anytime soon, would it be possible to move the editorial (undisputed) stuff (trailing comma, authz -> challenge in URL) into this PR?
NAME I think I've gotten all the trailing commas and errant headersgit di.
NAME Looks good to me!
editorial clarifications, looks good to me.
Change:
restriction, the certificate is acceptable.  Otherwise, relying party or the relying party software rejects the certificate. <del> When a single software has capability to process various data </del> <ins> When a single software has the capability to process various data </ins> formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc).

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
freshness (RFC7234 Section 4.2.2.) greater than that indicated by the DNS Record with the smallest TTL in the response. <del> Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. </del> A DNS API Server MUST be able to process application/dns- udpwireformat request messages.

Discussion:
The draft explicitly prohibits ETag, which suggests that we don't care for revalidation requests at the HTTP layer (and reliance on the resolver cache). I don't think that's necessary. Revalidation requests are a feature HTTP provides. It might be that the cost of serving revalidation is comparable to the cost of making a genuine request. DNS responses are generally modest in size. But using that as the basis of a decision here might foreclose on some use cases, for which it might be annoying to have to revise the protocol to support. Right now, I don't see a concrete reason to prohibit revalidation, ETag, Last-Modified, and the works. If we consider the DNS API server as authoritative for its view of the state of particular resource records, then all these things can be used. For instance, Last-Modified can refer to the time that the DNS API server last received a response (or even when it last received a response that changed its cached value, which is a different view on this). That said, the rough model I described in seems to suggest that DNS TTL limits what HTTP can do. If that model is correct, and both the DNS stack and API server cache right up to the TTL, then HTTP caching can't add any value.
It doesn't prohibit etag (well, at least the author wasn't trying to have it do that).. as you say, revalidation is a feature HTTP provides and its not cool for a foo over http draft to mess with that. Similar thing with 304 - 304 isn't real useful here and the draft is trying to steer you away from it in the name of quality of implementation.. but 304 is going to mean what HTTP says 304 means, doh doesn't have the hubris to change that. there is a triggering non-normative 'should' in the mix. it does try and explain that they aren't that helpful here - but I guess that's really based on the pov that the DoH Server is a gateway to traditional DNS. In that scenario, which the draft talks about, a stale resource will probably revalidate because the traditional DNS side can't revalidate. I guess you could do some kind of byte for byte comparison and use 304 as a way to extend the ttl.

and of course, there is no reason the DoH server can't just plain be the terminal authoritative server and thus easily do revalidation based on something other than the DNS protocol. based on those thoughts I'll try and find a PR that downgrades this to "FYI - writing revalidation code might not be that impactful"
feedback from singapore is to change to text so that it doesn't discourage revalidation but instead explores the space a bit
Change:
to preserve security properties such as forward secrecy of messages or post-compromise security. <del> 2.4. </del> <ins> 2.3. </ins> New Members to the Messaging Service will always need to provide some initial keying material for other users to potentially use when

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
algorithm such as the following.  If the decoder encounters a value of EncodedInsertCount that could not have been produced by a conformant encoder, it MUST treat this as a connection error of type <del> "HTTP_QPACK_DECOMPRESSION_FAILED". </del> <ins> QPACK_DECOMPRESSION_FAILED. </ins> TotalNumberOfInserts is the total number of inserts into the decoder's dynamic table.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
aggregating invalid inputs. This capability is no stronger than any aggregator's ability to <del> forge validity proof shares in collusion with a malicious client. </del> <ins> forge validity proof in collusion with a malicious client. </ins> Relaying messages between aggregators.  The leader can compromise availability by dropping messages.

Discussion:
Remove terms which are infrequently used (and in a few cases, remove the unnecessary references) Clean up a few terms which appear to be defined incorrectly.
Change:
config), "tls ech config id", 8)", unless it is optional for an application; see optional-configs. "config" is the "ECHConfig" structure.  "Extract" and "Expand" are as specified by the cipher <del> suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </del> <ins> suite KDF.  (Passing the literal "" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "payload" field.

Discussion:
The backtick-quoted empty string translates to """" in the text output.
Not sure if this is the best solution, but the quadruple quote in the txt is goofy.
This seems fine, yeah. Thanks for catching it!