jiebi/CodeConvo huggingface dataset:
Change:
have a string key that maps to any value.  Used to indicate a generic JSON object. <del> All timestamps and time-related values (e.g., offsets) in qlog are logged as "float64" in the millisecond resolution. Other qlog documents can define their own CDDL-compatible (struct) types (e.g., separately for each Packet type that a protocol supports). </del> 1.1.2. While the qlog schemas are format-agnostic, and can be serialized in

Discussion:
In the main schema document, there's a a chunk of text that says: The danger with restating things like this is that there is some subtle problem or incompatibility with the canonical CDDL source citation. I appreciate the QUIC WG might not be familiar with this syntax, so it's handy. But the long-term problems a more insidious. Consider replacing it with deep links to CDDL syntax, or sticking it behind a note that it will be removed prior to publication.
Yes, the intent is to remove this prior to publication. It's just there to make early adoption easier for now. Will look up how to properly add such a note (not sure if there's something default in the kramdown for that) and add it.
Change:
8. <del> Since TLS 1.3 introduce a large number of changes to TLS 1.2, the </del> <ins> Since TLS 1.3 introduces a large number of changes to TLS 1.2, the </ins> list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this reason this section focuses on the most important changes only.

Discussion:
Add references to RFC 768: UDP RFC 4347: DTLS 1.0 RFC 4346: TLS 1.1 RFC 6347: DTLS 1.2 RFC 5246: TLS 1.2 in the Introduction section. Currently they are mentioned but with no citations.
Change:
The time considerations in this example are equivalent to those discussed under Example 1 above. <del> 15.5. </del> <ins> 16.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any

Discussion:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.
Change:
On receiving a delegated credential and a certificate chain, the client validates the certificate chain and matches the end-entity <del> certificate to the server's expected identity following its normal procedures.  It also takes the following steps: </del> <ins> certificate to the server's expected identity in the usual way.  It also takes the following steps: </ins> Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more <del> than 7 days. </del> <ins> than 7 days.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. <del> Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements. </del> <ins> Verify that the end-entity certificate satisfies the conditions in certificate-requirements. </ins> Use the public key in the server's end-entity certificate to verify the signature of the credential using the algorithm

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
8.11. <ins> The generic "$QuicFrame" is defined here as a CDDL extension point (a "socket" or "plug").  It can be extended to support additional QUIC frame types. The QUIC frame types defined in this document are as follows: </ins> 8.11.1. In QUIC, PADDING frames are simply identified as a single byte of

Discussion:
In doing the exercise to try and define a new DATAGRAM extension for qlog (at URL), it became clear that we only had a CDDL extension point for the events themselves () but NOT for the individual QUIC and HTTP/3 frames. This is needed so we can add the CDDL definitions for new frames in other documents and have them properly matched to the CDDL expectations of "main document" events like and .
LGTM modulo some editorial nits
Change:
software.  However, end-users might also be facing some attacker's client software, without even realizing it. <ins> end-user / AS: when the client supports it (see response- interact), the end-user gets to interact with front-channel URLs provided by the AS. </ins> client/AS: An honest AS may be facing an attacker's client (as discussed just above), or the reverse, and GNAP aims at making common attacks impractical.  The core specification makes access

Discussion:
May later make a link to security considerations related to phishing attacks but currently the section has not been merged in trunk, so it would create an error
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0dd7278bfa3604409da8bb8ea4ddc6983824cdb2 Inspect the deploy log: Browse the preview:
To be described (interactions)
Change:
resolution, when support mechanisms such as TURN or ICE are used to establish connectivity, if protocols or paths are raised, or if a path fails and fallback or re-establishment is supported in the <del> Transport Services system. </del> <ins> Transport Services system.  Applications should take special care when using 0-RTT session resumption (see prop-0rtt), as early data sent across multiple paths during connection establishment may reveal information that can be used to correlate endpoints on these paths. </ins> Applications should also take care to not assume that all data received using the Transport Services API is always complete or well-

Discussion:
"In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire.": There has been a warning on the privacy implications of using the same token on different paths; doesn't sending an identical 0-RTT message racingly on multiple transports cause similar correlation issues?
This may be better to put in the privacy and security considerations section of the API document, particularly that doing cleartext 0-RTT data that races can be recognized on the path (as opposed to being in TLS which fixes this).
Similarly, connection racing overall can let a server observe that a client has multiple addresses and what they are, etc.
LGTM; note that I left a tiny comment.
Change:
section for all Source RTP Streams using the specified media formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified <del> in RFC4585, Section 4.2.  When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. </del> <ins> in RFC4585, Section 4.2.  When sending RTCP feedback, follow the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. </ins> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue

Discussion:
Originally raised by Magnus: When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. This is okay, but could be slightly more open in regards to sending feedback packets efficiently. Section 5.4.1 in URL is providing more detailed rules for things to consider.
Magnus, what do you think is needed here. Informative ref ?
A reference would be good. I would consider cutting away the explicit recommendation here and only say that "When sending RTCP feedback, follow the rules and recommendations in Section 5.4.1 of [draft-ietf-avtcore-rtp-multi-stream] to select which SSRC to use."
Change:
The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic <del> protection and detection of non-compliant connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing </del> <ins> protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing </ins> overhead of client-to-server packets. 5.3.1.

Discussion:
and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
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.
Thanks, this is a lot easier to read for me.
Change:
Compute the COSE object as specified in sec-obj-cose the AEAD nonce is created by XORing the Sender IV (context IV) <del> with the Sender Sequence Number (partial IV). </del> <ins> with the Sender Sequence Number in network byte order (partial IV). </ins> If the block option is used, the AAD includes the AEAD Tag from the previous block sent (from the second block and following)

Discussion:
This should fix issue
As per Christian Amsüss' message from 2017-01-04 we should clarify how we expect implementers to map sequence numbers to partial IV's. I think that network-byte order is a good way.
Change:
Abstract <del> This document changes the IANA registry policy for a number of registries related to DTLS and TLS, renames some of the registries for consistency, and adds notes to many of the registries.  As a result, this document updates many RFCs (see updates header). </del> <ins> This document describes a number of changes to D/TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process.  This document updates many (D)TLS RFCs (see updates header). </ins> 1.

Discussion:
A pretty major rewrite to incorporate the rationale for changes into individual sections as opposed to having it at the beginning. Also fixing some formatting.
Change:
1.2 remain in this version.  Thanks to Mark Nottingham for doing the markdown translation. <ins> [RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH] The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/tlswg/tls13-spec . Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the TLS mailing list. </ins> The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.  The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake

Discussion:
Provide a temporary URL in the draft for people wanting to submit pull requests, so that they don't have to search the archives for Sean's message from April 17.
We should probably wrap long lines that reviewing is a little easier. The rest of the doc wraps at 80.
Change:
If the server negotiates an earlier version of TLS, or if it does not provide an "encrypted_server_name" extension in EncryptedExtensions, the client proceeds with the handshake, authenticating for <del> ESNIConfig.public_name as described in auth-public-name.  If an earlier version was negotiated, the client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If authentication or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT treat this as a secure signal to disable ESNI. </del> <ins> ESNIConfigContents.public_name as described in auth-public-name.  If an earlier version was negotiated, the client MUST NOT enable the False Start optimization RFC7918 for this handshake.  If authentication or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT treat this as a secure signal to disable ESNI. </ins> Otherwise, when the handshake completes successfully with the public name authenticated, the client MUST abort the connection with an

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.
Change:
4.2.6. <del> The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header set from server to client on a request stream, as in HTTP/2. </del> <ins> The PUSH_PROMISE frame (type=0x5) is used to carry a promised request header set from server to client on a request stream, as in HTTP/2. </ins> The payload consists of:

Discussion:
Simply making this consistent through the document by doing the minimal change and removing leading 0s. Happy to add them if we prefer.
Works for me.
Change:
In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of <del> a connection, following the phases described in TAPS-ARCH.  An example interface sketch in Go is shown in appendix-api-sketch. </del> <ins> a connection, following the phases described in TAPS-ARCH. </ins> 5.

Discussion:
Appendix B of the API draft provides a sample concrete definition of the API, written in Go. Having concrete examples of the API is clearly useful, but I question whether this draft is the right place for them, since we don't want to bless a particular API variant. Suggest this appendix be moved to either the implementation draft, or a separate example API implementation draft.
The intention here is to show that the API is reasonably expressible and expressive in at least one modern language. I'd be more than happy to replace it with links to the code and documentation for now though. (Eventually, examples would be more useful than the sketch though.)
NAME makes sense.
Looks good to me.Looks good to me
Change:
transmitted during the life of a conference. Thus, endpoints MUST maintain a list of SSRCs from received RTP flows <del> and each SSRC's associated E2E Key(i) information.  Following a change of the KEK (i.e., EKTKey), prior E2E Key(i) information SHOULD be retained for a period long enough to ensure that late-arriving or out-of-order packets from other endpoints can be successfully decrypted.  The endpoint MUST discard the E2E Key(i) and KEK information no later than when it leaves the conference. </del> <ins> and each SSRC's associated E2E key information.  Following a change in an E2E key, prior E2E keys SHOULD be retained by receivers for a period long enough to ensure that late-arriving or out-of-order packets from the endpoint can be successfully decrypted.  Receiving endpoints MUST discard old E2E keys no later than when it leaves the conference. </ins> If there is a need to encrypt one or more RTP header extensions end- to-end, an encryption key is derived from the end-to-end SRTP master key to encrypt header extensions as per RFC6904.  The Media Distributor will not be able use the information contained in those <del> header extensions encrypted with E2E keys. </del> <ins> header extensions encrypted with an E2E key. </ins> 4.4.

Discussion:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM
Change:
Acknowledgment-based loss detection implements the spirit of TCP's Fast Retransmit (RFC5681), Early Retransmit (RFC5827), FACK (FACK), <del> SACK loss recovery (RFC6675), and RACK (RACK).  This section provides an overview of how these algorithms are implemented in QUIC. </del> <ins> SACK loss recovery (RFC6675), and RACK-TLP (RACK).  This section provides an overview of how these algorithms are implemented in QUIC. </ins> A packet is declared lost if it meets all the following conditions:

Discussion:
and part of
Alissa Cooper said:
NAME said:
Good point, also 4.7 currently has TLP in the title, but doesn't use it anywhere else in the section, so I'll add some text on TLP too. URL
Please also update the RACK reference to version 14. draft-ietf-tcpm-rack-14
The version update is part of the toolchain we use, so the newest version of RACK should be referenced automatically.
Change:
For each parent of the common ancestor, up to the root of the tree, derive a new path secret and set the private key for the node to the private key derived from the path secret.  The <del> private key MUST be the private key that correspondns to the </del> <ins> private key MUST be the private key that corresponds to the </ins> public key in the node. Use the "epoch_secret" from the KeyPackage object to generate the

Discussion:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thank you!
Change:
OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide the PSK identity (as a character string) and key (as a byte string).  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del> <ins> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline.

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
processing in the filter expression: Its only argument is an instance of "NodesType" (possibly taken from <del> a "filter-query" as in the example above).  The result is an instance of "ValueType". </del> <ins> a "filter-query", as in the example above).  The result is an instance of "ValueType". </ins> If the argument contains a single node, the result is the value of the node.

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
FAILED without sending a message to the helper.  Otherwise it interprets "out" as follows.  If this is the last round of VDAF preparation phase, then "out" is the leader's output share, in which <del> case the leader finishes.  Otherwise, it interpresets "out" as the </del> <ins> case the leader finishes.  Otherwise, it interprets "out" as the </ins> tuple "(new_state, outbound)", where "new_state" is its new preparation state and "outbound" is its next VDAF messaage, and continues with "outbound" as its next VDAF message.  Either way, it

Discussion:
While implementing upload today, I also noticed some inconsistencies between the handling of reports in the leader during the upload protocol and the helper