jiebi/CodeConvo huggingface dataset:
Change:
A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time <ins> 3.7. In the Fast IDentity Online (FIDO) protocol WebAuthN, CTAP, the device in the user's hand authenticates the human user, whether by biometrics (such as fingerprints), or by PIN and password.  FIDO authentication puts a large amount of trust in the device compared to typical password authentication because it is the device that verifies the biometric, PIN and password inputs from the user, not the server.  For the Relying Party to know that the authentication is trustworthy, the Relying Party needs to know that the Authenticator part of the device is trustworthy.  The FIDO protocol employs remote attestation for this. The FIDO protocol supports several remote attestation protocols and a mechanism by which new ones can be registered and added.  Remote attestation defined by RATS is thus a candidate for use in the FIDO protocol. Other biometric authentication protocols such as the Chinese IFAA standard and WeChat Pay as well as Google Pay make use of attestation in one form or another. Every FIDO Authenticator contains an Attester. Any web site, mobile application back end or service that does biometric authentication. </ins> 4. dataflow depicts the data that flows between different roles,

Discussion:
Address . There are on the order of 1 billion users of biometric authentication
Discussion: everything you can do, RATS can do better :) Aka every authentication/access control use case is an attestation use case. Laurence to take a first shot at adding text into intro above use cases. Details would be in a doc from FIDO or W3C.
FIDO and Android are attestation use cases with billions of users today and are different from all the ones currently listed, so at least one of them should be added.
Ok to merge
Change:
system objects that may be temporarily unavailable. Separate from events, callbacks are also provided for asynchronous <del> interactions with the Transport Services API, which are not directly </del> <ins> interactions with the Transport Services API that are not directly </ins> related to events on the network or network interfaces. 2.2.

Discussion:
Clarified one use of word "API" comes just after discussion of the socket API. Tried to fix specialised features to say they define additional requirements. Minor changes to wording, with no intended changes to substance.
LGTM but I made one very small comment
Change:
path, the transport system will try the path first, ignoring the preference. <del> Both Selection and Connection Properties can be added to a Preconnection to configure the selection process, and to further configure the eventually selected protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object: </del> <ins> Selection, and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the selection process, and to further configure the eventually selected protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object: </ins> Individual properties are then added to the TransportProperties Object:

Discussion:
This came up in a dinner among some of us yesterday: all UDP messages should be understood as being idempotent, because UDP doesn't protect the receiver against getting duplicates. This is different from unreliable transmission with, e.g., SCTP (or, probably, a future such extension of QUIC?), where you can be sure you're not getting a duplicate.
wfm
Change:
"ECHConfigContents.cipher_suites" list. The HPKE encapsulated key, used by servers to decrypt the <del> corresponding "payload" field.  This field is empty in ClientHelloOuters sent in response to HelloRetryRequest. </del> <ins> corresponding "payload" field.  This field is empty in a ClientHelloOuter sent in response to HelloRetryRequest. </ins> The serialized and encrypted ClientHelloInner structure, encrypted using HPKE as described in real-ech.

Discussion:
Just some minor nits I picked up during a slow pass of the spec.
LGTM pending one nit.
Change:
Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del> <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed.

Discussion:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!
Change:
Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del> <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed.

Discussion:
This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.
Change:
7.3.4. <del> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jws" in string form. The signer creates a JWS RFC7515 object as follows: </ins> To protect the request, the JWS header contains the following claims.

Discussion:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc
Change:
RESET_STREAM frame (frame-reset-stream) with an appropriate error code to terminate just the affected stream. <del> RESET_STREAM MUST be instigated by the protocol using QUIC. RESET_STREAM carries an application error code.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an </del> <ins> Resetting a stream without the involvement of the application protocol could cause the application protocol to enter an unrecoverable state.  RESET_STREAM MUST only be instigated by the application protocol that uses QUIC. RESET_STREAM carries an application error code, for which the semantics are defined by the application protocol.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an </ins> automatic RESET_STREAM. <del> Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. </del> Application protocols SHOULD define rules for handling streams that are prematurely cancelled by either endpoint.

Discussion:
This cribs Lucas' proposed tweak and makes a few other tiny adjustments.
The transport currently says It feels more correct to say I'll prepare a PR if my understanding and suggestion is correct.
It's a subtle point, but it seems OK. I do find the use of a possessive in that phrasing abhorrent though.
I made a stupid typo, whoops. Open to alternative phrasing. "Pulling the rug" comes to mind...
You're changing the meaning here, and I think the existing phrasing is correct. If you don't understand the application protocol, you don't know which streams are safe to reset and which will be connection-fatal. Telling the application protocol that you reset the stream doesn't make it any less fatal if you reset the wrong stream.
So looking at the paragraph in entirety I agree with NAME : directly or through the receipt of a STOPSENDING frame from a peer. RESETSTREAM carries an application error code. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. Is the intention to describe why " RESET_STREAM MUST be instigated by the protocol"? The words following the normative text are a bit wooly/weasely. I think this paragraph slightly falls victim to the problem that you raised on URL but from the other side of the coin. Nowhere else do we use the phrase "protocol using QUIC" - it sounds a bit bcp56(bis).
Yes -- QUIC doesn't unilaterally reset streams, because it doesn't have the context to do so safely. The application layer on one of the peers has to do that, even if it does so via a STOP_SENDING transmitted by QUIC.
Small commentslgtm
Change:
packet.  Though packets might still be in flight or awaiting acknowledgment, no further Initial packets need to be exchanged beyond this point.  Initial packet protection keys are discarded (see <del> Section 4.9.1 of QUIC-TLS) along with any loss recovery and </del> <ins> Section 4.10.1 of QUIC-TLS) along with any loss recovery and </ins> congestion control state (see Section 6.5 of QUIC-RECOVERY). Any data in CRYPTO frames is discarded - and no longer retransmitted

Discussion:
and 4.9.1 are now 4.10 and 4.10.1, I believe.
Change:
Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are <del> described in RFC8655.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet-mpls.  The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means is provided by the underlying technology.  For example, encryption may be used, such as that provided by IPSec RFC4301 for IP flows and/or by an underlying sub-net using MACSec IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows. </del> <ins> described in RFC8655. DetNet MPLS data plane specific considerations are summarized and described in I-D.ietf-detnet-mpls including any application flow types.  This document focuses on the scenario where TSN Streams are the application flows for DetNet and it is already covered by those DetNet MPLS data plane security considerations. </ins> 8.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
requests for recursion.  It will "not normally generate any queries of its own.  Instead, it answers non-recursive queries from iterative resolvers looking for information in zones it <del> serves."  (Quoted from RFC4697, Section 2.4) </del> <ins> serves."  (Quoted from RFC4697, Section 2.4) In this case, "ignores requests for recursion" means "responds to requests for recursion with responses indicating that recursion was not performed". </ins> The act of a client requesting a copy of a zone and an authoritative server sending the needed information.  (See zones

Discussion:
There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".
Change:
Section 4.4.2. The certificate message contains an opaque string called <del> certificate_request_context.  The format of certificate_request_context is defined by the application layer protocol and its value can be used to differentiate exported authenticators.  For example, the application may use a sequence number used by the higher-level protocol during the transport of the authenticator to the other party.  Using a unique and unpredictable value ties the authenticator to a given context, allowing the application to prevent authenticators from being replayed or precomputed by an attacker with temporary access to a private key. </del> <ins> certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is provided, it is zero-length. </ins> This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate.

Discussion:
Add new "authenticator request" message Make Certificate selection more explicit (including extensions) Update API considerations accordingly
I update the draft in response to the comments.
Two small comments: Can you add text explaining why authenticator requests are not encrypted with handshake keys? (Are they encrypted at all?) It might help to include a sequence diagram or two showing intended uses of exported authenticators, e.g., for Mike's draft, and where requests fit into TLS connections.
NAME I'm not sure what purpose encrypting them would serve. The draft does say that "The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport." In other words, the messages have integrity built-in and any desire for confidentiality is the app's to solve.
NAME I was referring to the following sentence: "This message is not encrypted with a handshake key, which differs from how this message is used in TLS 1.3." Perhaps you could add text explaining why this choice was made?
By the time you use this, handshake keys might be long gone. I think that we could avoid this confusion by stating that this is only the handshake messages and not records that form the authenticator. And maybe add that because there are no records, there is no record protection.
Change:
operation that involves merging input sets while avoiding duplicates, so the concept was renamed into "list selector". <del> 3.4.9.1. </del> <ins> 3.4.8.1. </ins> The list selector is syntactically related to the "dot-selector", "index-selector", "slice-selector", and the "filter-selector".  It contains two or more entries, separated by commas. <del> 3.4.9.2. </del> <ins> 3.4.8.2. </ins> A list selector selects the nodes that are selected by at least one of the selector entries in the list and yields the concatenation of

Discussion:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!
Change:
to-machine communication across networks of constrained devices. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources.  Depending on the <del> situation the same device may act either as a server or a client. </del> <ins> situation the same device may act either as a server, a client, or both. </ins> One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging

Discussion:
This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).
Change:
via separate communication. The actual data format and semantics of any Reference Values are <del> specific to Claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. </del> <ins> specific to Claims and implementations. </ins> 3.3.

Discussion:
Signed-off-by: Dave Thaler
While Reference Values have a strong focus on conveyance and data format, Appraisal Policies do not. Is there a specific reason for this asymmetry? Additionally, there is a statement on scope on the Reference Value that does not exist for Appraisal Policies. Does that imply something?
Add some additional words to Appraisal policy like: URL
Agreed to also move to section 6, about appraisal/etc. combinations.
Change:
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id).  Connection IDs that are issued and not retired are considered active; any active connection ID is <del> valid for use at any time, in any packet type.  This includes the connection ID issued by the server via the preferred_address transport parameter. </del> <ins> valid for use with the current connection at any time, in any packet type.  This includes the connection ID issued by the server via the preferred_address transport parameter. </ins> An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs.  Endpoints store received

Discussion:
This isn't strictly necessary, as it might be implied by the definition of a connection ID. I tried tweaking the connection ID definition, but it is hard to say anything concrete because of the way that addressing can also be used in combination with connection IDs to identify a connection at an endpoint. So I left that alone.
I agree that a connection ID identifies one session, and due to forbidden correlation, it is clear that a connection ID in use cannot proliferate. However, this is not implied for newly issued connection IDs. There is precedence for new tokens which do apply to new connections, so I think it is worth being precise here.
added the text " Connection IDs that are issued and not retired are considered active; any active connection ID is valid for use at any time, in any packet type. " As far as I can tell there is no text specifying that an issued connection ID cannot be used with subsequent connections. The introduction to connection IDs state that there must not be correlation across connections, but if an issued connection ID was never consumed, there would be no correlation because it was transmitted encrypted.
Not really sure if this is necessary. The text around this sentence implies that connection IDs identify one connection (which shouldn't be too surprising in the first place). It's only when you take this one sentence out of context, that the "problem" of occurs.
Change:
Rendezvous() on a Preconnection with a source-specific multicast group address as the Local Endpoint results in an EstablishmentError. <del> "RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress) RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress) RemoteSpecifier.WithPort(PortNumber) RemoteSpecifier.WithTTL(TTL) LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress) LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress) LocalSpecifier.WithPort(PortNumber) LocalSpecifier.WithTTL(TTL) " </del> See multicast-examples for more examples. 6.1.2.

Discussion:
Review the use of and markdown in the API document, and make it consistent.
A fantastic PR! The best ever!
Change:
If the tree has "2^d" leaves, then it has "2^(d+1) - 1" nodes.  The "ratchet_tree" vector logically has this number of entries, but the <del> sender SHOULD NOT include blank nodes after the last non-blank node. If a receiver encounters a vector whose length "L" is not of the form "2^(d+1) - 1", then the receiver MUST extend it to the right with blank values until it has such a length, adding the minimum number of blank values possible.  (Obviously, this may be done "virtually", by synthesizing blank nodes when required, as opposed to actually changing the structure in memory.) </del> <ins> sender MUST NOT include blank nodes after the last non-blank node. The receiver MUST check that the last node in "ratchet_tree" is non- blank, and extend it to the right until it has a length of the form "2^(d+1) - 1", adding the minimum number of blank values possible. (Obviously, this may be done "virtually", by synthesizing blank nodes when required, as opposed to actually changing the structure in memory.) </ins> The leaves of the tree are stored in even-numbered entries in the array (the leaf with index "L" in array position "2*L").  The root

Discussion:
As discussed in mlswg/mls-implementations . Currently, there are several valid for one tree: the sender can choose ("SHOULD") to omit some (but not all) blank nodes at the right of the tree. This PR changes this: the sender MUST omit all the blank nodes at the right of the tree, and the receiver MUST check that it was done correctly (i.e., the last node of is non-blank).
Right now, the signature on an MLSPlaintext includes the GroupContext for the group. If we are going to allow Add proposals signed by the new member, then this will need to change, because the new member doesn't know the GroupContext. My preference would be to simply remove the GroupContext from the plaintext. The Group ID is already included, so copy/paste protection can be added that way. The other elements of the GroupContext effectively overlap with the Epoch that is already signed.
Haven't thought about this too deeply, but having the full GroupContext in MLSPlaintextTBS means that we know all the members agree on the state of the ratchet tree, the transcript, the extensions. Removing it means we would no longer have agreement on those, right?
We won't have confirmation of agreement as a result of signature verification. The question is whether that is necessary. If the MLSPlaintext was decrypted from an MLSCiphertext, for example, then the successful decryption of the MLSCiphertext implies agreement on all those things. I suppose you could also switch the signature input based on SenderType, but that seems messier.
I'm not so sure that decrypting an MLSCiphertext implies agreement, because the crypto is symmetric. A man-in-the-middle can re-encrypt but not re-sign.