jiebi/CodeConvo huggingface dataset:
Change:
address and port) in addition to the ICE parameters. STUN connectivity checks between agents are authenticated using the <del> short-term credential mechanism defined for STUN [RFC5389].  This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server.  The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon.  Each agent also provides a password, used to compute the message integrity for requests it receives.  The username fragment and password are exchanged between the peers.  In addition to providing security, the username provides disambiguation and correlation of checks to media streams.  See Appendix B.4 for motivation. </del> <ins> short-term credential mechanism defined for RFC5389.  This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server.  The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon.  Each agent also provides a password, used to compute the message integrity for requests it receives.  The username fragment and password are exchanged between the peers.  In addition to providing security, the username provides disambiguation and correlation of checks to media streams.  See sec-why-uname for motivation. </ins> If the initiating agent is a lite implementation, it MUST indicate this when sending its candidates .

Discussion:
It looks like two references didn't get translated into xml2rfc xref tags when RFC 5245 got imported.
LGTM! Thanks!
Change:
or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as <del> names) to given values at the given time(s). </del> <ins> names) to given values at the given time(s).  The semantics of the target resource supporting this usage can be described, e.g., using I-D.ietf-core-interfaces.  Examples of actuation usage are shown in thermo-ex. </ins> 5.

Discussion:
target are such that SenML is interpreted as configuration/actuation"? And aren't configuration and actuation quite different use cases? These semantics need to be established out of band from SenML point of view. Could be something like CoRE interface type or LwM2M resource type that accepts SenML for this purpose. But we don't want to be prescriptive here. Perhaps giving example(s) is good approach
Addressed by PR
Change:
(See batch-validation.) However, Aggregators are also required to implement several per- <del> report checks that require retaining a number of data artificts.  For </del> <ins> report checks that require retaining a number of data artifacts.  For </ins> example, to detect replay attacks, it is necessary for each Aggregator to retain the set of report IDs of reports that have been aggregated for the task so far.  Depending on the task lifetime and

Discussion:
Historically, the Nonce included a time component. Now that the time component is split out & Nonce is effectively an opaque identifier, ReportID is clearer & more closely matches similar identifiers (TaskID, AggregationJobID, BatchID).
Note this PR includes a single wire-format change: had its fields reordered so that the comes first, since the ID is the primary identifier. I am happy to revert this part of the PR if folks would prefer a purely-editorial PR.
LGTM. Any thoughts on replacing and with a Nonce so then it has both?
I'm pretty happy leaving & as separate fields -- for practical purposes, IMO binds them together closely enough (along with the report extensions). Conceptually, DAP is changing such that the primary identifier for a report is its opaque ID (with this PR, called ). Previously, the primary identifier for a report was . The technical aspects of this change were made by cjpatton in his changes to introduce tasks. If we do decide to introduce a struct that is effectively , I'd prefer if it was called something other than -- while we do expect that this value is a "value to be used only once", it's no longer used as a nonce in any cryptographic operations. And I'd argue there's no better justification to call the report ID (or ) a nonce than, say, the aggregation job ID/batch ID/task ID. That is, IMO "report ID" more accurately names what this type is than "nonce" -- "nonce" is not technically incorrect, just less clear.
Currently, the DAP specification has a number of opaque values used to identify some DAP entity: (identifying a client report) (identifying a task) (identifying an aggregation job) (identifying a batch) 's name differs from the rest. I think this is because, historically, the nonce also included a time component. Now that the time component has been split out, I think we could rename to for clarity of purpose. Thoughts? (and I probably don't need to say this, but there is no reason to push this into DAP-02 -- it could easily land in DAP-03 instead.)
Yup, I think this is a good idea!

I'm tempted to say let's stick this in 02, since it's editorial, but it's actually somewhat invasive because we use the term "nonce set" in so many places. If you want to send a PR, I'd review it. But we should make sure there's broad consensus before merging.
Nice change Yeah I think this is a big win :) good idea NAME
Change:
this could allow a malicious peer to exhaust processing capacity without consequence. <del> QUIC prohibits the sending of empty "STREAM" frames unless they are marked with the FIN bit.  This prevents "STREAM" frames from being sent that only waste effort. </del> While there are legitimate uses for some redundant packets, implementations SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack.

Discussion:
Of the TLS doc says: A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents QUIC from sending 0-RTT data. However, this doesn't explicitly say that it prevents QUIC from receiving 0-RTT data. I suspect this is implied, but it might be worth clarifying. I could imagine a server rejecting 0-RTT data, but attempting to ACK the client's 0-RTT packets in order to deliver a congestion signal to the client. I think this would be a rather terrible idea, so it would be nice to explicitly prohibit it.
Throughout transport, there is the idea that you MUST not acknowledge packets you can't fully process, so this should be against the spec. But it may be worth noting explicitly, probably in transport.
Doing it in transport would make sense. Or perhaps in TLS by noting that if 0-RTT is rejected, 0-RTT keys must not be generated.
NAME I just added text about that to my PR that's targeting .
SG NAME If so, can you update the CL description to indicate what issues it closes?
I'm going so recommend that this be triaged as a design issue, even if it might seem trivial. The prohibition in is the right response.
The spec says RFC 8446 says about rejecting 0-RTT: This doesn't really apply to QUIC, since we don't need a connection that requires us to read the bytes in order. The QUIC equivalent would be to drop all packets of packet type 0-RTT.
It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0-RTT (or not). Merely dropping the packets is not sufficient. This is because the parameters of a connection depends on if 0-RTT has been received; for example, in case of HTTP/3, until the client receives a SETTINGS frame, the settings of previous connection is applied when 0-RTT is accepted, whereas the default settings defined by the specification is applied when 0-RTT is rejected.
PS. What I think we need to clarify is that "use and acceptance" of 0-RTT is communicated the same way as TLS 1.3, by using the earlydata extension.

That includes earlydata extension sent in ClientHello, EncryptedExtensions, NewSessionTicket.
Thanks NAME That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.
Change:
including the key in the PEM file returned in response to a query for a certificate URL. <del> When processing an file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </del> <ins> When processing a file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </ins> certificates.  If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.

Discussion:
Change "applicaiton" to "application"
With any luck we'll have to catch this in the RFC editor queue; hopefully there won't be another draft.
Thanks NAME
Change:
IDs from other QUIC versions in order to properly form a version negotiation packet. <del> The Source Connection ID field follows the SCID Len and is between 0 and 20 bytes in length. negotiating-connection-ids describes the use of this field in more detail. </del> <ins> The Source Connection ID field follows the SCID Length field and is between 0 and 20 bytes in length. negotiating-connection-ids describes the use of this field in more detail. </ins> In this version of QUIC, the following packet types with the long header are defined:

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been split by the AS, the value of the "label" field is chosen by the <del> AS and the "split" field is included and set to "true". </del> <ins> AS and the "split" flag is used. </ins> OPTIONAL.  The management URI for this access token.  If provided, the client instance MAY manage its access token as described in

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: bf6004c8584efbaf8dc30f3637ba0c61bc000d84 Inspect the deploy log: Browse the preview:
NAME The editors would like to give you credit for all these contributions, can you please give us your name as you'd like it to appear in the acknowledgements section? Thank you!
Change:
If the client instance indicates that it can request-interact- usercode and the AS supports this mode for the client instance's <del> request, the AS responds with a "user_code" field.  This field is an object that contains the following members. The client instance MUST communicate the "code" to the end user in some fashion, such as displaying it on a screen or reading it out audibly.  This code is used by the interaction component of the AS as a means of identifying the pending grant request and does not </del> <ins> request, the AS responds with a "user_code" field.  This field is string containing a unique short code that the user can type into a web page.  This string MUST be case-insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than eight characters in length.  REQUIRED. The client instance MUST communicate the "user_code" value to the end user in some fashion, such as displaying it on a screen or reading it out audibly.  This code is used by the interaction component of the AS as a means of identifying the pending grant request and does not </ins> function as an authentication factor for the RO. The URI that the end user is intended to enter the code into MUST be

Discussion:
Instead of using an object with a single member, the interaction start method now uses a simple string, in line with the and methods.
To edit notification comments on pull requests, go to your .
Change:
Reference: Where this algorithm is defined <ins> This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle unknown token types gracefully (this technique is inspired by RFC8701).  Implemenations SHOULD select reserved values at random when including them in greased messages.  Servers can include these in TokenChallenge structures, either as the only challenge when no real token type is desired, or as one challenge in a list of challenges that include real values.  Clients can include these in Token structures when they are not able to present a real token response.  The contents of the Token structure SHOULD be filled with random bytes when using greased values. </ins> The initial contents for this registry are defined in the table below.

Discussion:
Updated to use random values
NAME please take a look!
Origins can issue challenges for greased token types, etc, to ensure client can handle new types in the future.
One type of greasing might be adding random authentication credentials to the header, e.g., .
We should recommend servers to send greased token types + parameters, as well as clients to send greased credentials.
Change:
"batch_interval" is the batch interval of the request. "agg_param", an aggregation parameter for the VDAF being executed. <ins> This is the same value as in "AggregateInitializeReq" (see leader- init) and in "CollectReq" (see collect-init). </ins> "report_count" is the number of reports included in the aggregation.

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:
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC. <ins> This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes.  This affects Initial packets and path validation. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud).

Discussion:
URL the path doesn't provide extra headroom. Includes some rewording of the text.
Éric Vyncke said:
We wanted some space for things like extension headers/options and maybe for tunnels. See which is in response to your peer Erik. And yeah, 1200 is a nice number.
Based on the discussion here and the linked issue, I don't think we need to do anything here.
Erik Kline said:
Seems reasonable to mention. Obviously many paths support a larger MTU and so will support more extensions (or options), but it's worth noting that there isn't a ton of space available.
Change:
endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making <del> these connections identifiable based on the usage of the spin bit, it is recommended that all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </del> <ins> these connections identifiable based on the usage of the spin bit, all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </ins> When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT).

Discussion:
This sentence is rather supposed to explain what's done in QUIC then giving any recommendation, therefore we can simply remove the "recommended" phrasing.
Change:
The secret key and the nonce are values derived by calling HKDF- Expand-Label using <del> 0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c as </del> <ins> 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as </ins> the secret, with labels being "quic key" and "quic iv" (protection- keys).

Discussion:
Also, examples use final version numbers. IMPORTANT: the TLS extension codepoint needs to be updated, both in the text and in the examples (which will result in changes to authentication tags and the affected ciphertext).
I plugged the test vectors into the quiche test suite and it checks out URL
Hey there! We are currently implementing the Initial packet encryption process and it successfully works with the client Initial example from the appendix A.2 of the QUIC-TLS draft. However, when running tests with values for the server Initial example from the appendix A.3, tests regarding the parsing, header sampling, header protection and final encryption result all succeed, except for the header protection mask: the value we generate is: , while the draft explicitly specifies it should be something completely different: . Note that the value we generate is indeed used later on for the header protection and final encryption result, which both reveal successful. Therefore, three possibilities we thought of, in ascending order of probability: Our implementation is completely broken. The mask value provided by the current version of the specification (A.3) is correct, but all others are incorrect. Only the mask value is incorrect, while the rest is correct. We think the last option is the most probable one, as it could just mean it was forgotten to be updated in a recent draft version. If you think this is the case as well, then I would gladly open up a PR in order to close this, I just wanted to make sure beforehand. Otherwise, I would happily accept a tad of guidance towards a correct implementation. Thanks in advance, Paul.
Investigated a bit more. Looking at the result of a , we can see that: 2ebdfd53a is indeed meant to update example vectors, but does it only partially it seems: while 2ebdfd53a is for other secrets, but did it completely. So it should confirm our hypothesis.
hi NAME Our editors are taking some slight respite, we'll respond soon.
No problem NAME I was just adding some more information I forgot to mention yesterday. Thanks for the heads up :+1:
It seems to me that the header is not correct. Thoughts?
For me the header looks fine: it is consistent with the final result. What looks wrong to you NAME
I'll assign this to NAME since I think that is his code.

I can confirm this, but it won't matter as -33 will have new values entirely. The mask value should be 56fb1381e7 for the second example.
NAME would you link this issue to the PR that will update the values for -33 so it gets closed then?
New values seem to work in my testing.
Change:
Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the <del> same host listening to the same TCP port).  They are distinct namespaces and are considered to be distinct origin servers. </del> <ins> same host listening to the same TCP port).  They are hosted in distinct namespaces because each URI scheme implies a distinct origin server. </ins> The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of

Discussion:
URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.