jiebi/CodeConvo huggingface dataset:
Change:
output of AEAD_AES_128_GCM (AEAD) used with the following inputs: The secret key, K, is 128 bits equal to <del> 0xccce187ed09a09d05728155a6cb96be1. </del> <ins> 0xbe0c690b9f66575a1d766b54e368c84e. </ins> <del> The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c. </del> <ins> The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb. </ins> The plaintext, P, is empty.

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:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-14 Ensure that a signature public key is always intelligible (*) Clean up terminology of derived secrets/keys Fix parent hash (*) Specify compatibility behavior around new credentials Add Path Required to Proposal Type template Sub-group branching requires fresh key packages for each member Use "aasvg" and typed code blocks Require init key and leaf key to be different Preconfigured senders extension and removal of signature key indirection </ins> draft-13 TLS syntax updates (including variable-header-length vectors) (*)

Discussion:
This should have been done before publishing draft-14, but we can't fix that now. At least this will capture the history in draft-15.
Merging my own PR because this is strictly editorial.
Change:
A single KeyShareEntry value for the negotiated cipher suite. <del> Servers MUST NOT send a KeyShare for a group not offered by the client. </del> <ins> Servers MUST NOT send a KeyShareEntry value for a group not offered by the client. </ins> Servers offer exactly one KeyShareEntry value, which corresponds to the key exchange used for the negotiated cipher suite.

Discussion:
Fix spacing to match other flow charts & fix one KeyShare->KeyShareEntry that was missed.
Change:
However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The <del> protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del> <ins> "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS.  A mechanism for more robust protections is discussed in I-D.ietf-mls- extensions.  A DS can cause a partition in the group by partitioning key exchange messages; this can be detected only by out of band comparison (e.g., confirming that all clients have the same "epoch_authenticator" value`). </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply

Discussion:
Comment by NAME It scares me a bit that this could possibly not be detected at all? What is the scenario where it cannot be detected?
It's actually non-trivial to guarantee detection. Consider a scenario like the following: A, B, C, D are in a group The DS decides to partition the group into (AB) (CD) The DS forwards commits and messages within a partition, but not across partitions. As a result, the two subgroups work fine, but they diverge from each other This will be immediately obvious if two participants in opposite partitions ever try to compare state across the partition boundary, say by checking whether a message arrived or even by comparing the value. But it will be invisible if nobody does -- it just looks like the other partition is offline at the moment. And note that comparing across the partition boundary has to be done out of band, because the DS is blocking in-band comms across the boundary. To prevent this with any reliability, you would need a consensus protocol by which a quorum of members verify that they've received a Commit. And even then, the members outside any particular quorum could be partitioned. In any case, designing a consensus protocol is clearly outside the MLS WG charter. The silver lining here, as the document notes, is that the protocol fails closed. If two members have different views of the group, then they cannot communicate.
This is only true wrt to handshake messages. The DS can still reorder and provide an inconsistent view of application messages. We intentionally punted this to an extension (which I realize now we never specified in the extensions doc) to give applications leeway in the ordering/delivery guarantees provided to application messages. Handshake messages require reliable and in-order but application messages may or may not.
Change:
7.5.7. <del> Assuming ESNI records retrieved from DNS are validated, e.g., via </del> <ins> Assuming ESNI records retrieved from DNS are authenticated, e.g., via </ins> DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See cleartext-dns for more details regarding cleartext DNS. <del> Validating the ESNIKeys structure additionally validates the public name.  This validates any retry signals from the server because the client validates the server certificate against the public name before retrying. </del> <ins> Authenticating the ESNIKeys structure naturally authenticates the included public name.  This also authenticates any retry signals from the server because the client validates the server certificate against the public name before retrying. </ins> 7.5.8.

Discussion:
Based on comments in Montreal, I believe that the authors no longer intend to document the partial-split configuration.
Change:
specification does not describe prioritization between the RTP streams that come from a single "media source". <ins> All media flows in WebRTC are assumed to be interactive, as defined in RFC4594; there is no browser API support for indicating whether media is interactive or non-interactive. </ins> A "data flow" is the outgoing data on a single WebRTC data channel. The priority associated with a media flow or data flow is classified

Discussion:
Notes that there's no way to mark a stream as non-interactive.
From discussion with DSCP folks:
after
Discussion people: Cc: EMAIL; EMAIL; EMAIL; EMAIL; Black, David
I chose to integrate this minus the G.1010 reference, since I did not know how to get that reference in using XML2RFC markup, and the reference to 4594 already covers it.
Fixed in (version -14)
Change:
to those that would be sent by an invocation of Initiate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established <del> will not result in a SendError separate from the InitiateError </del> <ins> will not result in a SendError separate from the EstablishmentError </ins> signaling the failure of Connection establishment. 7.2.6.

Discussion:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.
Change:
because it helps describe the DNS and naming systems similar to the DNS. <del> An ordered list of zero or more labels. </del> <ins> An ordered list of one or more labels. </ins> Note that this is a definition independent of the DNS RFCs, and the definition here also applies to systems other than the DNS.

Discussion:
Shouldn't that be "An ordered list of one or more labels"? If not, I'd like to see some text specifically addressing the zero-length case.
Change:
defines how the bytes in the compressed_certificate_message field are converted into the Certificate message. <del> A peer is not required to compress their own Certificate messages even if the compress_certficates extension has been negotiated, but MUST be able to decompress a received CompressedCertificate message. If the negotiated compression algorithm is zlib, then the Certificate </del> <ins> If the specified compression algorithm is zlib, then the Certificate </ins> message MUST be compressed with the ZLIB compression algorithm, as <del> defined in RFC1950.  If the negotiated compression algorithm is </del> <ins> defined in RFC1950.  If the specified compression algorithm is </ins> brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in RFC7932.

Discussion:
This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state. This also decouples client and server compression parameters, allowing compression being negotiated in only one direction.
LGTM, added just a couple of small nits.
Looks good to me.
Change:
with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a <del> source of call linkage I-D.ietf-rtcweb-ip-handling </del> <ins> source of call linkage I-D.ietf-rtcweb-ip-handling. </ins> 4.4.2.

Discussion:
Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.
Change:
Caching and pre-fetching of tokens is discussed in caching. <del> Note that it is possible for the WWW-Authenticate header to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header could look like this: </del> <ins> Note that it is possible for the WWW-Authenticate header field to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header field could look like this: </ins> Origins should only include challenges for different types of issuance protocols with functionally equivalent properties.  For

Discussion:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list
Change:
Use the "Expand" function provided by the same KDF to extract an AEAD key "key", of length "Nk" - the length of the keys used by <del> the AEAD associated with "context".  Generating "key" uses a label of "key". </del> <ins> the AEAD associated with "context".  Generating "aead_key" uses a label of "key". </ins> Use the same "Expand" function to extract a nonce "nonce" of length "Nn" - the length of the nonce used by the AEAD. <del> Generating "nonce" uses a label of "nonce". </del> <ins> Generating "aead_nonce" uses a label of "nonce". </ins> Encrypt "response", passing the AEAD function Seal the values of <del> "key", "nonce", empty "aad", and a "pt" input of "request", which yields "ct". </del> <ins> "aead_key", "aead_nonce", an empty "aad", and a "pt" input of "response", which yields "ct". </ins> Concatenate "response_nonce" and "ct", yielding an Encapsulated Response "enc_response".  Note that "response_nonce" is of fixed-

Discussion:
Section 4.2, prose says whereas the pseudo-code says
A few things here should improve readability: key -> aeadkey, nonce -> aeadnonce, then we should be sure to pass the response in rather than the request.
Nice catch on s/request/responseLGTM
Change:
11. <del> TDB </del> <ins> 11.1. An implementation should take care to handle different PMTU sizes across multiple paths.  One simple option if the PMTUs are relatively similar is to apply the minimum PMTU of all paths to each path.  The benefit of such an approach is to simplify retransmission processing as the content of lost packets initially sent on one path can be sent on another path without further frame scheduling adaptations. </ins> 12.

Discussion:
Add some implementation considerations to handle different PMTU sizes following the discussion on . Feel free to add different implementation options here.
Looks ok to me, just a small suggestion to avoid talking about packet retransmission.
Change:
Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a <del> unidirectional stream can send data on it.  Due to offset encoding limitations, a stream can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, the stream can simply be closed and replaced with a new one. </del> <ins> unidirectional stream can send data on it. Due to encoding limitations on stream offsets and connection flow control limits, both streams and connections can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, a new connection would need to be established. </ins> Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a

Discussion:
This text in is incorrect. When you have sent that much data, the connection flow control limit cannot be increased further. Consequently, though many additional streams can be opened when a stream hits this limit, you cannot send any bytes on any of those streams. I recommend striking this sentence or replacing it with a note about this fundamental limit applying to all data conveyed in streams.
Happy to take a PR :-)
Pretty good. Thanks.
Change:
Next, it checks that the sequence of Transition messages corresponds to the ReportShare sequence of the AggregateInitReq.  If any message <del> appears out of order or is missing, or a transition has an unrecognized nonce, then the leader MUST abort with error "unrecognizedMessage". </del> <ins> appears out of order, is missing, has an unrecognized nonce, or if two messages have the same nonce, then the leader MUST abort with error "unrecognizedMessage". </ins> Next, for each Transition, the leader proceeds as described in prep- leader.  If any state transition results in INVALID, this indicates

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq
Change:
13.22. During the interaction process, the client instance usually hands <del> control of the user experience over to another component, beit the </del> <ins> control of the user experience over to another component, be it the </ins> system browser, another application, or some action the resource owner is instructed to take on another device.  By using an interaction finish method, the client instance can be securely

Discussion:
type, - beit -> be it,
To edit notification comments on pull requests, go to your .
"beit" isn't a word, it should be "be it".
As I was reading through the latest version of the draft, I spotted a typo within section 2.1.1. It should says accesstoken object, not acccess_token object.
Change:
3.3.2. The cloud registrar returned a voucher to the pledge.  The pledge <del> should perform voucher verification as per standard BRSKI operation. The pledge should verify the voucher signature using the manufacturer-installed trust anchor(s), should verify the serial number in teh voucher, and must verify any nonce information in the </del> <ins> SHOULD perform voucher verification as per standard BRSKI operation. The pledge SHOULD verify the voucher signature using the manufacturer-installed trust anchor(s), SHOULD verify the serial number in the voucher, and SHOULD verify any nonce information in the </ins> voucher. <del> The pledge should extract the "est-domain" field from the voucher, and should continue with EST enrollment as per standard BRSKI </del> <ins> The pledge SHOULD extract the "est-domain" field from the voucher, and SHOULD continue with EST enrollment as per standard BRSKI </ins> operation. 4.

Discussion:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".
Change:
types like custom and local tags such as "!!python/object" and "!mytag" (see Section 2.4 of YAML); <del> 3.4. </del> <ins> 3.5. </ins> To allow fragment identifiers to traverse alias nodes, the YAML representation graph needs to be generated before the fragment

Discussion:
looks good to me (with one minor editorial note i left as a comment).
Would it be valuable to express a preference for over for file extensions? I'm assuming 3 character extensions are legacy from DOS file systems that had a 3 character limit. I reviewed the YAML 1.2 spec and there is no mention of using as a file extensions, so this might be a good opportunity to steer the community away from having two extensions.
Pls let's annihilate the DOS zombie!
NAME let's summon NAME and the YAML folks on that. IMHO: agree on expressing a preference disagree on removing references to .yml, since it's used in the wild. My2¢, R.
Discussed with YAML folks. Ok for indicating a preference without normative implications.
Change:
Abstract JSONPath defines a string syntax for selecting and extracting values <del> within a JavaScript Object Notation (JSON, RFC 8259) value. </del> <ins> within a JSON (RFC 8259) value. </ins> 1. <del> JavaScript Object Notation (JSON, RFC8259) is a popular representation format for structured data values.  JSONPath defines a string syntax for identifying values within a JSON value. </del> <ins> JSON RFC8259 is a popular representation format for structured data values.  JSONPath defines a string syntax for identifying values within a JSON value. </ins> JSONPath is not intended as a replacement for, but as a more powerful companion to, JSON Pointer RFC6901.  See json-pointer.

Discussion:
because it is no longer needed because the expansion is misleading
Why is the expansion misleading?
I would have thought it was because the notation is not just for objects.
Using the expanded version of the acronym gives the impression that this specification is in some way entangled with JavaScript. (The fact that Glyn reads "JavaScript Object" as a reference to the string-keyed maps JavaScript started out with is another example for the confusion.)
I feel like anyone who knows about JSON had likely come across our asked about its relationship with its namesake. I don't really think this is something that is needed. I mean, do it if it makes you feel better, but it's not really necessary.
In the RFC series, the expansion is no longer needed, which is a good thing, because the expansion is misleading. This PR adapts the JSONPath specification to this fact. I'm not sure what "this" and "it" are in your message. This PR is not about making anyone of us feel better, it is about improving the document to be less misleading.
I think we are all agreed that merging is fine.
LGTM, thanks.
Change:
(If we missed your name, please let us know!) <del> 10.  References </del> <ins> 11.  References </ins> <del> 10.1.  URIs </del> <ins> 11.1.  URIs </ins> [1] https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons

Discussion:
Yes, lets add it. Well, I really don't want to imply that right provisioning requires QoS or at least some DSCP marking. Yes, to many, the answer could be just providing enough bandwidth for others, it could be a bit more complicated. If you have seen my recent ANRW talk, I refer to the "QoS" as the first camp (slide 5) and many efforts to date simply failed in that aspect. Paper: URL Slides: URL
I like this text. I have thoughts. Do we need a reference for "bufferbloat"? We haven't used that term in the document yet, and I agree with using it here. I note . I agree with "the right provisioning", but for someone not skilled in the art, that may be like "and then a miracle occurs", and I suspect a lot of people still assume "the right provisioning" means something like "the right bandwidth provisioning", which isn't what we mean at all, is it? ISTM that we might (1) mention DSCP, (2) mention URL as something to be aware of.