jiebi/CodeConvo huggingface dataset:
Change:
3. Pre-shared Key (PSK) ciphersuites were first specified for TLS in <del> 2005.  Now, PSK is an integral part of TLS 1.3 specification [RFC8846].  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use- cases where pair-wise external PSKs with TLS have been used for authentication.  Note that the following list is non-exhaustive: </del> <ins> 2005.  Now, PSK is an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs with TLS have been used for authentication.  Note that the following list is non- exhaustive: </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

Discussion:
Moved links in use cases sections to references and made the text somewhat more concise. Added some initial text on known attacks.
Change:
In the Composite Device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the claims from its Target <del> Environment(s).  The lead Attester collects the Evidence of all other Attesters and then generates the Evidence of the whole Composite Attester. </del> <ins> Environment(s).  The lead Attester collects the Evidence from the other Attesters and conveys it to a Verifier.  Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester.  The lead Attester generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules. </ins> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can

Discussion:
Updated paragraph describing collection of Evidence from sub-attesters
Should this section include an Informative Reference to the Trusted Computing Group “Guidance for Securing Network Equipment” URL It seems to repeat more or less the same thing, but using the RATS lexicon
Another comment I have on this section is about the trust model of a composite device: it looks like the lead attester needs to be trusted to collect the most fresh evidence from the other slots? Is this discussed anywhere?
Who do you mean the lead Attester needs to be trusted by? The Verifier/Relying Party or other slots/Attesters? The collecting capability is one of the characteristics the lead Attester has. So after the Verifier verifies the Evidence of the lead Attester successfully, it can trust the lead Attester's collecting capability. The Evidence of other slots are signed by these slots themselves, and these slots can send Evidence to the lead Attester just as the lead Attester sends Evidence to the on-path router to the Verifier.
I meant the latter - apologies for the lack of precision. In particular, I am interested in the scenario where a compromised lead that has cached some previously collected evidences, can forward those instead of fresh slots' attestations.
Change:
decryption failure.  It is up to the application and the key manager to define how long this period is. <del> 3.3. </del> <ins> 3.4. </ins> Every client in the call knows the secret key for all other clients so it can decrypt their traffic, it means a malicious client can

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such <del> messages by sending an Abort message and otherwise ignoring the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </del> <ins> messages by sending an Abort message and otherwise ignoring (not processing) the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </ins> 5.7.

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
4.1.2. <del> [TODO] </del> <ins> The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same "LS" group when creating an offer or answer.  addTrack attempts to minimize the number of transceivers as follows: The track will be attached to the first compatible transceiver (of the same media type) which has never had a direction of "sendonly" or "sendrecv".  If no such transceiver exists, then one will be constructed as described in sec.addTransceiver. </ins> 4.1.3.

Discussion:
I'd suggest that we try to move forward with this and leave the exact ruleset as an open issue pending Peter's investigation.
OK, I updated the PR to have the MST text. I think we had Cullen's r+ so ready to merge?
Merging this and will file an issue on the algorithm.
Change:
maximum value it can represent, the endpoint MUST use the largest representable value instead. <del> A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value larger than 16,383,000 microseconds is invalid, as specified for the "max_ack_delay" transport parameter.  Any value smaller than the "min_ack_delay" advertised by this endpoint is invalid. Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay" (Section 18.2 of QUIC-TRANSPORT).  The value of this field is in microseconds, unlike the 'max_ack_delay' transport parameter, which is in milliseconds.  Sending a value smaller than the "min_ack_delay" advertised by the peer is invalid.  Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01

Discussion:
Fixes the remainder of not fixed by
This is good enough. You have a conflict to resolve, but let's merge this.
Change:
considerations apply. When using YAML as a more efficient format to serialize information <del> intented to be consumed as JSON, information can be discarded: this </del> <ins> intended to be consumed as JSON, information can be discarded: this </ins> includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart.

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
but MAY be held constant for successive connections to the same server in the same session. <del> Set the "config_digest" field to a randomly-generated string of "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </del> <ins> Set the "config_id" field to a randomly-generated string of "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM.

Discussion:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)
Change:
The message contains the following parameters: The DAP task ID.  If the Helper does not recognize the task ID, it <del> MUST abort with HTTP status code 400 Bad Request and error "unrecognizedTask". </del> <ins> MUST abort with error "unrecognizedTask". </ins> The "batch selector", which encodes parameters used to determine the batch being aggregated.  The value depends on the query type

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged
Change:
This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcpmux </del> <ins> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux </ins> and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's

Discussion:
NAME NAME PTAL
This LGTM. Have you run it through a parser? If not, I'm going to give that a shot.
Addressed all comments, save the parser. PTAL.
LGTM. Fluffy?
LGTM - I did not really have time to review it but again, looks close enough I'd like to see it merged into the draft and that will make it easier to fix any nits.
Change:
Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this document. <del> 6.1. </del> <ins> 7.1. </ins> IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" sub- registry, within the "CoRE Parameters" registry RFC7252.  The assigned IDs are shown in tbl-coap-content-formats. <del> 6.2. </del> <ins> 7.2. </ins> Type name: application

Discussion:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.
Change:
7.3.1. This method is indicated by "httpsig" in the "proof" field.  The <del> sender creates an HTTP Message Signature as described in I-D.ietf- </del> <ins> signer creates an HTTP Message Signature as described in I-D.ietf- </ins> httpbis-message-signatures. The covered content of the signature MUST include the following:

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use
Change:
CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment (see sending-acknowledgements). <ins> A packet that does not increase the largest received packet number for its packet number space by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.

Discussion:
From recovery to transport.
currently states: NAME notes that nowhere do we define precisely how a receiver might do this detection. Specifically a receiver could implement this as when a newly received packet is smaller than the largest acked, or as when the packet is larger than largest acked plus one. Doing the former would actually not help with loss detection, since the receiver would not ack immediately on a gap. We should add some text codifying the latter.
That section used to be in recovery, where we have a definition already(which is now unused), so I'd suggest we move it over. "Out-of-order Packets: : Packets that do not increase the largest received packet number for its packet number space by exactly one. Packets arrive out of order when earlier packets are lost or delayed."
Isn't this supposed to be "Packets that increase the largest received packet number ... by more than one." in this case?
Thinking about this some more, there are three possible definitions here for out-of-order: a newly received packet is greater than largest received by more than one, a newly received packet is smaller than the largest received, both (1) and (2). (1) is the obvious case where a loss happens and a subsequent packet is received. (2) is the reordering case, where an earlier packet is delivered later, and while it does not indicate loss, it does indicate that a gap was filled. It's useful to signal (2) as well immediately to prevent a sender from unnecessarily retransmitting what it believes to be a missing packet. The definition we want for "out-of-order" is the one that is most useful for determining when to send an immediate ack. The definition in the PR captures both (1) and (2), and is probably the one we want.
NAME : If you believe we ought to change the definition, please re-open, and we can continue this discussion.
Thank you for working on this.
Change:
protocol permits. For large data transfers, small record sizes can materially affect <del> performance TARREAU.  Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed. </del> <ins> performance.  Every record incurs additional costs, both in the additional octets for record headers and for expansion due to encryption.  Processing more records also adds computational overheads that can be amortized more effectively for larger record sizes.  Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed. </ins> This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets.  However, RFC 6066 requires that

Discussion:
And simply explain what the costs of smaller records actually are.
Great summary. Thanks for adding the text. One minor question: My reading of the referenced email discussion is that the computational overhead is not just a matter of cryptographic processing but also the processing related to multiplexing, TCP-related processing and other implementation details (e.g., threading). Is this also your understanding of what the folks in the email thread were referring to?
My understanding is that the performance costs are largely due to context switching. That might be worse because of multiplexing. Willy did a separate talk on the costs of doing crypto at high data rates that I wish that I could reference. He had some great numbers about what it took just to move data from the kernel to user space and that was a significant impact on overall throughput.
Change:
4.1. <del> PENDING: Discuss how two different subscriptions are correlated based on either authentication or connection </del> <ins> The aggregation of multiple subscriptions into a subscription set can represent a significant efficiency improvement for a push service. For that reason, if a subscription set is available, a user agent MUST indicate an existing subscription set in a request to create a subscription.  However, a user agent MAY omit the subscription set if it is unable to receive push messages that are aggregated for the lifetime of the subscription.  This might be necessary if the user agent is forwarding requests from other clients. The user agent adds a subscription set link relation to the request to create a subscription.  This indicates which subscription set the subscription is to be bound to. This gives the push service the option to create a subscription within an existing subscription set.  The push service returns the same subscription set in the response, though it MAY use a new subscription set if it is unable to reuse the provided one. A push service MAY reject a request if it contains an unknown or invalid subscription set, or a request that does not include a subscription set.  An 429 status code can be used to indicate that too many requests to create subscriptions sets were made. How a push service detects that requests come from the same user agent is implementation-dependent and could take ambient information into consideration, such as the TLS connection, source IP address and port.  Implementers are reminded that using some heuristics can produce false positives and cause requests to be rejected incorrectly. </ins> 5.

Discussion:
This replaces the PENDING section on correlation. I know that NAME wanted to simply rely on ambient authority of some sort, but I think that this is the cleanest option. It doesn't cost us anything significant either.
Does the PS return the push:set with each subscribe response or just the first one? If returned in all cases, can the push:set change between responses? If so, does the UA MUST use the latest one? For a PS that wants to strongly require aggregation - besides using concurrent stream limits - can it return an error if the push:set is not included?
Good questions, both of them, I'll add a commit that answers them (rather than answer them in these comments).
Answers provided (more words added)...
Change:
portal API endpoint, conforming to the recommendations for such URIs [draft-ietf-capport-api]. <del> A captive portal server MAY redirect requests that do not have an Accept header field (RFC7231 Section 5.3) containing a field item whose content-type is "application/capport+json" to the URL conveyed in the "user-portal-url" API key.  When performing such content negotiation (RFC7231 Section 3.4), implementors of captive portals need to keep in mind that such responses might be cached, and therefore SHOULD include an appropriate Vary header field (RFC7231 Section 7.1.4) or mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3). </del> A captive portal MAY do content negotiation (RFC7231 section 3.4) and attempt to redirect clients querying without an explicit indication of support for the captive portal API content type (i.e. without application/capport+json listed explicitly anywhere within an Accept header vis.  RFC7231 section 5.3).  In so doing, the captive portal SHOULD redirect the client to the value associated with the "user- <del> portal-url" API key. </del> <ins> portal-url" API key.  When performing such content negotiation (RFC7231 Section 3.4), implementors of captive portals need to keep in mind that such responses might be cached, and therefore SHOULD include an appropriate Vary header field (RFC7231 Section 7.1.4) or mark them explicitly uncacheable (for example, using Cache-Control: no-store RFC7234 Section 5.2.2.3). </ins> The URI SHOULD NOT contain an IP address literal.

Discussion:
""" It looks like the two consecutive paragraphs that both begin with “A captive portal” have some duplication with regard to the absence of “Accept” headers; please check that and adjust if you agree that some information can be merged or removed. """ Indeed, these paragraphs seem to be saying almost the exact same thing. I think the 2nd paragraph can be removed, once it's clear whether/how to move its SHOULD to the 1st paragraph.
A bunch of unrelated changes :)