jiebi/CodeConvo huggingface dataset:
Change:
It SHOULD contain TLS padding RFC7685 as described in padding. <del> The client then constructs the ClientHelloOuter message just as it does a standard ClientHello, with the exception of the following rules: </del> <ins> If it intends to compress any extensions (see outer-extensions), it MUST order those extensions consecutively. The client then constructs EncodedClientHelloInner as described in outer-extensions.  Finally, it constructs the ClientHelloOuter message just as it does a standard ClientHello, with the exception of the following rules: </ins> It MUST offer to negotiate TLS 1.3 or above. <del> Any extensions compressed as described in outer-extensions must match the ClientHelloInner.  [[OPEN ISSUE: When #331 and compression ordering is resolved, be a bit more precise here.]] </del> <ins> If it compressed any extensions in EncodedClientHelloInner, it MUST copy the corresponding extensions from ClientHelloInner. </ins> It MAY copy any other field from the ClientHelloInner except ClientHelloInner.random.  Instead, It MUST generate a fresh

Discussion:
Along the way, I've made two additional tweaks: Renamed outerextension to outerextensions, now that it contains multiple extensions. One of the diagrams even already referred to "outerextensions" because I didn't realize it was called "outerextension".Clarified in compression process and ClientHelloInner construction rules that the to-be-compressed extensions must be consecutive. Hopefully that helps with .
NAME FYI. I'm hoping this will help clarify why the ordering thing isn't actually a big deal.
I've updated the PR to include text to disambiguate the serialization. It's ambiguous whether the encoding includes the 4-byte (12-byte in DTLS) header from the Handshake structure or is just the body, from the ClientHello structure. I've picked the smaller one. This also saves having to answer, in DTLS, what happens when the inner sequence number is wrong.
There are two ClientHelloInners, the actual one used in the handshake, and the encoded one with outerextensions substituted in. Both are described as ClientHelloInner, but this makes it slightly ambiguous which goes into, say, the handshake transcript. (It's late now, so I'll leave this as an issue without a PR. If we don't end up resolving this separately, I'll probably fix this as part of . If we decide to implicitly copy over legacysession_id, the encryption payload becomes less and less defensibly an actual ClientHelloInner.)
In my own implementation, I've been referring to the plaintext payload as CompressedClientHelloInner. Which is terrible, but unambiguous.
Works for me. I was thinking EncodedClientHelloInner because it's shorter and still works even if you choose not to compress anything. (A no-op encoding is still an encoding.)
+1 to EncodedClientHelloInner, given that compression is optional. NAME if you have time, could you whip up a PR?
Change:
provisioning domain, measurements by the protocol stack, or other sources.  They can only be queried. <del> appendix-specify-query-params gives a more detailed overview of the different types of properties that can be set and queried at different times. </del> 9.1. Protocol Properties represent the configuration of the selected

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:
The lifetime of the socket is tied to the request stream.  The proxy MUST keep the socket open while the request stream is open.  If a proxy is notified by its operating system that its socket is no <del> longer usable, it MUST close the request stream.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the request stream when closing the socket.  Proxies that close sockets after a period of inactivity SHOULD NOT use a period lower than two minutes, see BEHAVE. </del> <ins> longer usable (for example, this can happen when an ICMP "Destination Unreachable" message is received, see ICMP6), it MUST close the request stream.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the request stream when closing the socket.  Proxies that close sockets after a period of inactivity SHOULD NOT use a period lower than two minutes, see BEHAVE. </ins> A successful response (as defined in resp1 and resp23) indicates that the proxy has opened a socket to the requested target and is willing

Discussion:
With the CONNECT UDP, a proxy will send and receive UDP datagrams on behalf of a client. However, in addition to these UDP datagrams, it could also receive ICMP messages. The current draft does not discuss how these ICMP messages should be handled by a proxy and how they would need to be conveyed to the client. It probably makes sense to at least discuss how ICMP destination/network/port unreachable should be handled by the proxy (ignore, terminate the HTTP connection, ...)
I agree. I'm not yet sure what the best solution is (closing the stream on port unreachable would improve reliability but does introduce a way for an attacker to deny service) but we should figure that out and provide guidance in the doc.
FWIW, the way TURN handles this is by having a way for the server to forward ICMP indications. URL Obviously, in order to have this in MASQUE we would need to have some sort of type indicator in the datagram.
I do want the relevant information in the ICMP to make it to the client. However, ICMP falls into the asynchronous information that is not directly associated with a forwarded packet. It can clearly be a forwarded packet per EKR's suggestion. We have other cases where we have information that is related to the associated packet, for example ECN. So I think this there is an important high level design choice here that we need to sorted out. I think for the general extensibility lets consider a content identifier so that just UDP payloads can be separated from additional types with additional fields.
Change:
dated 2007-02-21 JSONPath-orig and provides a normative definition for it. <del> inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. </del> <ins> inspired-by-xpath describes how JSONPath was inspired by XML's XPath XPath. </ins> JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead

Discussion:
XPath details are a distraction in the body of the spec. In the future, readers are increasingly likely to come to this spec with no exposure to XPath or, for that matter, XML.
Looks very good, with the one nit. Thanks!
Change:
it MAY treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. <del> If the decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. </del> 2.2.2. The decoder signals the following events by emitting decoder

Discussion:
Emphasize that SETTINGSQPACKBLOCKED_STREAMS is set by the decoder. Move normative sentence on decoder encountering excessive number of blocked streams to this paragraph. Split note to separate paragraph.
:+1: This reads much better to me.
Change:
options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Discussion:
LGTM
lgtm
In URL 'certificates' is a set, and the PeerConnection selects which certificate to use. The SDP should have one 'a=fingerprint' line per certificate, and that is not reflected in the JSEP draft AFAICU.
Prague: One a=fingerprint line per cert, but we can go down to a single cert one DTLS has been established. The DTLS cert has to match one of the supplied a=fingerprints. (NAME correct as necessary)
PR added for allowing multiples. Processing rules go in the TBD applying section
Change:
Added an appendix with example code for tree math <ins> Changed the ECIES mechanism used by TreeKEM so that it uses nonces generated from the shared secret </ins> draft-00 Initial adoption of draft-barnes-mls-protocol-01 as a WG item.

Discussion:
This matches the behavior in TLS, and saves space (due to not having to send the nonce).
Merging based on r+ from NAME out of band
Change:
should be immediately closed by sending a RST to the peer (ABORT.TCP). <ins> Calling "CloseGroup" on a TCP Connection (CLOSE.TCP) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a TCP Connection (ABORT.TCP) is identical to calling "Abort" on this Connection and on all Connections in the same ConnectionGroup. </ins> 10.2. Connectedness: Connected

Discussion:
So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!
Change:
different connections; validating the port is therefore unlikely to be successful. <del> A token SHOULD be constructed to be easily distinguishable from tokens that are sent in Retry packets as they are carried in the same field. </del> <ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </ins> If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD

Discussion:
Although not super-important, the biggest decision in here is that the packet number of the response to a RETRY is 1. Based on interop experience, I believe this is the semi-consensus of implementers.
Should there be normative text mandating that the packet number be increased?
I think we need a new issue on that. The information about this is scattered around issuing CID's, path validation, retransmission of Initial. It would be good with a clear statement of when the packet number starts counting. I also believe that there is somewhere text to the effect that a CID cannot have the same PN twice, but that does not apply to Retry.
Change:
8.1.1. <del> The client exhausted its request-quota for the next 50 seconds.  The </del> <ins> The client exhausted its service-limit for the next 50 seconds.  The </ins> "time-window" is communicated out-of-band or inferred by the field values.

Discussion:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.
Change:
7. <del> Versioning in QUIC may change the the protocol's behavior completely, </del> <ins> Versioning in QUIC may change the protocol's behavior completely, </ins> except for the meaning of a few header fields that have been declared to be fixed.  As such version of QUIC with a higher version number does not necessarily provide a better service, but might simply

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
Sent by servers when a client certificate is desired but none was provided by the client. <ins> [[TODO: IANA Considerations for new alert values.]] </ins> New Alert values are assigned by IANA as described in iana- considerations.

Discussion:
There is no alert for a server which requested a client certificate, required it, but was not sent one. Servers today send a generic handshakefailure which means clients must use heuristics to show error messages to the user. Unlike nearly every other negotiation in TLS, client certificate selection is actually sometimes a user-level decision, so it is arguably the most important place for us to have a dedicated alert. (Also remove a "This alert is always fatal" note on badcertificatestatusresponse. All alerts are now fatal, so this is redundant.)
+1
Change:
Abstract <del> This document defines a YANG RPC and a small number of configuration node required to retrieve attestation evidence about integrity measurements from a device following the operational context defined </del> <ins> This document defines YANG RPCs and a small number of configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined </ins> in TPM-based Network Device Remote Integrity Verification. <del> Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device </del> <ins> Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), included in the device </ins> components of the composite device the YANG server is running on. 1.

Discussion:
Basically, this fixes typos, grammar, and consistency. And, all above, the TPM 2.0 quote information, which was set to TPMSQUOTEINFO. Actually it is TPM2B_ATTEST. Further Issues to be created.
TPM 2.0 quote information (attestation data) is of type TPM2BATTEST, not TPMSQUOTEINFO. TPMSQUOTEINFO is a sub element of the TPM2BATTEST. In a TPM2Quote operation, the TPM signs a hash of the TPM2BATTEST structure. The signature is of type TPMT_SIGNATURE (just FYI).
Change:
endpoints in conference to finish re-keying, senders MUST delay a short period of time before sending media encrypted with the new master key, but it MUST be prepared to make use of the information <del> from a new inbound EKTKey immediately.  See Section 2.2.2 of I- </del> <ins> from a new inbound EKT Key immediately.  See Section 2.2.2 of I- </ins> D.ietf-perc-srtp-ekt-diet. 5.

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:
This scheme is origin-server only and does not define a challenge. <del> 6.2. </del> <ins> 6.1. </ins> This creates a "Vapid Authentication Scheme Parameters" registry for parameters to the "vapid" authentication scheme.  This registry is

Discussion:
I know that it's the devil, but JSON is the obvious choice here.
Why would it be obvious ? application/x-www-form-urlencoded or a request parameter ?
It's an obvious choice given the proprietary precedence in the industry. I can't really judge the appropriateness of using JSON as opposed to an alternative -- this change LGTM assuming it is. Since the UA chooses the PS, there is no need for encryption. JSON provides good extensibility for additional (proprietary) data that may have to be transmitted over this channel.
At least it's not xml... I don't mind json - just didn't think it is so obvious. It does open an important question: will the user be allowed to pass more information to the push service (voluntarily) ? But +1 on this change.
Probably, but I don't want to think about that just yet :)
Change:
connection IDs), the short header exposes at most only a single connection ID. <del> Aside from the Destination Connection ID field of the first packets </del> <ins> Aside from the destination connection ID field of the first packets </ins> sent by clients, the connection ID can be zero length.  This is a choice that is made by each endpoint individually. An endpoint that selects a zero-length connection ID will receive <del> packets with a zero-length Destination Connection ID.  The endpoint </del> <ins> packets with a zero-length destination connection ID.  The endpoint </ins> needs to use other information, such as its IP address and port number to identify which connection is referred to.  An endpoint can choose to use the source IP address and port on datagrams, but this

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
ratchet of node index N in some epoch n.  Then, for that member, at least the following values have been consumed and MUST be deleted: <del> the "commit_secret", "joiner_secret", "member_secret", "epoch_secret", "encryption_secret" of that epoch n as well as the "init_secret" of the previous epoch n-1, </del> <ins> the "commit_secret", "joiner_secret", "epoch_secret", "encryption_secret" of that epoch n as well as the "init_secret" of the previous epoch n-1, </ins> all node secrets in the Secret Tree on the path from the root to the leaf with node index N,

Discussion:
This is a small suggestion to move the definition of the to the end of the first Extract-Expand (KDF) cycle of the [key schedule]. This makes more sense from a cryptographic perspective as we would not be using anything from the middle of a KDF cycle. A related suggestion is to remove the from the document. I removed it from the key schedule, removed all the mentions to forget it as soon as possible and updated the description of deriving the and from the [welcoming new members] section. [key schedule]: URL [welcoming new members]: URL
Thanks for the quick fix, NAME !
Change:
nomenclature for the other Handshake type names and to match with existing implementations. <del> Rename the SessionTicket TLS to session_ticket to match the nomenclature for the other extensions' names. </del> <ins> Rename the SessionTicket TLS extension to session_ticket to match the nomenclature for the other extensions' names. </ins> Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in RFC7301.

Discussion:
This PR and
ship it
From the draft: Remove one "are" from "are are reserved".
Remove the "it" from "cannot it" in the text below:
From the Introduction section: As far as I can see the above ought to be:
Change:
A Diffie-Hellman finite-field group or elliptic curve <del> A Derive-Key-Pair function that produces a key pair from an octet string </del> <ins> A Key Derivation Function (KDF) </ins> <del> A hash function </del> <ins> A Derive-Public-Key function that produces a public key from a private key </ins> A ratchet tree is a left-balanced binary tree, in which each node contains up to three values:

Discussion:
For now, I've only touched the sections until the "Cryptographic Objects" section, which seems to be outdated anyway. Once those are updated at some point, I'm happy to help moving from hashing to KDF-derivation there as well.
Thanks Konrad ! : )