jiebi/CodeConvo huggingface dataset:
Change:
material and the Attesting Environment with equivalent strength protections. <del> In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data to unauthorized parties.  The Verifier might share this information with other authorized parties, according rules that it controls.  In the background-check model, this Evidence may also be revealed to Relying Party(s). </del> <ins> 7.5. In some scenarios, the Endorser and Verifier Owner may need to trust the Verifier before giving the Endorsement and Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner- trust. </ins> 8.

Discussion:
Diffs look longer than they really are just because text was moved around due to the ordering point raised on the design team call. Also, I found that "Verifying Relying Party" was used in this section without actually being defined so I defined it in context in that sentence (line 686). Also added subsection headings for each role to make it easier to read and refer to. The "recursion" aspect is dealt with by example in the new text starting at line 692, which was the simplest way I could find to do it, where I found that trying to use the term "recurse" or similar just made it harder for me to understand. Other places just refer back to that example. Signed-off-by: Dave Thaler
Change:
deliver the data to the application immediately, as long as it is able to process the frame and can store the contents in memory. <del> DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. </del> <ins> Like STREAM frames, DATAGRAM frames contain application data and MUST be protected with either 0-RTT or 1-RTT keys. </ins> Note that while the max_datagram_frame_size transport parameter places a limit on the maximum size of DATAGRAM frames, that limit can

Discussion:
Section 5: says DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. I would suggest to add the "otherwise what happens" part. One/two like explanation will be helpful and I think that will improve the understanding of this requirement.
Almost all QUIC frame types are like this. I would suggest saying "Like STREAM frames, ..." to make this obvious for the rationale.
Change:
with the Transport Parameters (see transport-params).  This allows to specify Protocol Properties and that can be overridden on a per- Message basis or Application Intents that apply to a specific <del> Message.  See appendix-specify-query-params for an overview. </del> <ins> Message. </ins> Send Parameters may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is

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:
creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner. <del> Note that the long-term identity keys used by the protocol MUST be </del> <ins> Note that the long-term signature keys used by the protocol MUST be </ins> distributed by an "honest" authentication service for clients to authenticate their legitimate peers.

Discussion:
The public key in a credential is introduced without a special name and the field in the BasicCredential is currently called public_key, which is not very expressive. A few paragraphs below, it is referenced as "Identity Key" or simply "Identity", which is a bit misleading, as Credentials are supposed to contain an additional "identity" which is not the key. I propose we clear up the terminology a bit here and refer to the public key contained in a Credential as "Signature Key".
Change:
These values MAY either be present at the media level, or inherited from the session level. <del> ICE ufrag and password values </del> <ins> ICE ufrag and password values, which MUST comply with the size limits specified in RFC5245, Section 15.4. </ins> <del> DTLS fingerprint and setup values </del> <ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5, and MUST be consistent with the selected role of the current DTLS connection, if one exists.[TODO: may need revision, i.e., use of actpass DTLS fingerprint values, where at least one fingerprint MUST be present. Each m= section is also checked to ensure prohibited features are not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied: The session description must follow the rules defined in RFC3264, <del> Section 6. </del> <ins> Section 6, including the requirement that the number of m= sections MUST exactly match the number of m= sections in the associated offer. </ins> <del> For each m= section, the protocol value MUST exactly match the protocol value in the corresponding m= section in the associated offer. </del> <ins> For each m= section, the media type and protocol values MUST exactly match the media type and protocol values in the corresponding m= section in the associated offer. </ins> 5.7.

Discussion:
Still have a bunch of stuff to flesh out, but wanted to get this out for initial review. NAME NAME
Looks like good stuff to me. - The text in start of section 5 seem fine for making it clear that this does not override the referenced specs.
Thanks for the comments. Ran out of time to resolve them today but will take another shot at it Saturday.
Updated based on comments. I'd like to go ahead and merge this ASAP, and then hopefully still get another rev in before the deadline.
I'm fine with merging what we have here right now.
The text relies on the phrase "most recent gathering phase" to describe which candidates are present in SDP. Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section (or component thereof): when a new m= section is added (which happens for a new RTCPeerConnection obviously) when an m= section did have a port of 0, but is repurposed for new media (basically the same scenario as above) ICE restart This needs a clearer definition, or maybe just a single clear description of what it means to do this. This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription.
Martin, could you give us a PR that would satisfy you
Change:
pseudo-header fields after fields, <del> an invalid sequence of HTTP messages, or </del> <ins> an invalid sequence of HTTP messages, </ins> <del> the inclusion of uppercase field names. </del> <ins> the inclusion of uppercase field names, or the inclusion of invalid characters in field names or values </ins> A request or response that includes a payload body can include a "content-length" header field.  A request or response is also

Discussion:
The follow-on to ; depends on . DO NOT MERGE before lands. Imports most of the HTTP/2 Security Considerations text, modulo updates to reference HTTP/3 or http-core concepts. Suggestions on a more sensible structuring of concerns welcome; this still feels like a bit of a grab-bag.
There's a few places where it seems the new "field" terminology is applied inconsistently, but given the PR dependency chain maybe that will shake out. I'll take another look once other things have landed.
Given the chain, this PR should consistently use the new terminology. If I missed something, please flag it.
HTTP-core is making some terminology changes that HTTP/3 should track: In URL, "non-final" responses are "interim" responses In URL, terminology around header, field, value is changing Related to , but this is more than just pointing at the new documents.
NAME these comments/suggestion address my earlier one about use of headers. I might be applying things wrong.Looks good to me. Thanks for doing the hard work here.
Change:
sending a HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE <del> ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle ICE (i.e.  ICE lite media servers) or ICE restart, in that case, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request. </del> <ins> ufrag/pwd for ICE restarts. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If Trickle ICE or ICE restarts are not supported by the WHIP resource, it MUST return a 405 Method Not Allowed response for any HTTP PATCH request. </ins> As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource MUST generate a

Discussion:
While this is not ambiguous, it might be read as "MAY NOT". I suggest rewording as "Support for trickle ICE by WHIP resources is OPTIONAL".
NAME wdyt? is it ok to merge it and will this solve your concerns?
Yes, that's much better.
Change:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document. <del> IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in RFC5246, for request_connection_id (TBD), and new_connection_id (TBD), as defined in this document. </del> <ins> IANA is requested to allocate the following new values in the "TLS ContentType Registry": alert_with_cid(25) handshake_with_cid(26) application_data_with_cid(27) heartbeat_with_cid(28) </ins>

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.
Change:
input-share-decryption. Check that the resulting input share is valid as described in <del> input-share-batch-validation. </del> <ins> early-input-share-validation. </ins> Initialize VDAF preparation as described in input-share-prep.

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
the RO that the request has been completed. Meanwhile, the client instance loads the continuation information <del> stored at (3) and continue-request.  The AS determines which </del> <ins> stored at (2) and continue-request.  The AS determines which </ins> ongoing access request is referenced here and checks its state. If the access request has not yet been authorized by the RO in

Discussion:
Typo for section 1.4.3 Asynchronous Authorization, step 6: The continuation information was stored on step (2) not (3) as specified in the latest draft.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit befdba8ad92320248c4d011b13cca4f1dcb51f83 https://deploy-preview-245--gnap-core-protocol-editors-URL
Well spotted.
Change:
the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for <del> any operations.  TLS version 1.3 RFc8446 follows the same practice of </del> <ins> any operations.  TLS version 1.3 RFC8446 follows the same practice of </ins> specifying the psk identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1>). Implementations such as OpenSSL and mbedTLS nonetheless treat psk_identities as character strings and use string operators such <del> as strcmp on the psk identity. </del> <ins> as "strcmp" on the psk identity. </ins> Implementations also assign default identities to PSKs (for example, the string 'Client_identity') if none are configured.

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number (see nonce) and the client_write_iv or <del> server_write_iv, and the additional data input is empty (zero length).  Derivation of traffic keys is defined in traffic-key- calculation. </del> <ins> server_write_iv, and the additional data input is the record header. I.e., </ins> The plaintext input to the AEAD algorithm is the encoded <del> TLSInnerPlaintext structure. </del> <ins> TLSInnerPlaintext structure.  Derivation of traffic keys is defined in traffic-key-calculation. </ins> The AEAD output consists of the ciphertext output from the AEAD encryption operation.  The length of the plaintext is greater than

Discussion:
Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL
Change:
Version 772 corresponds to the hex representation 0x0304, named group "29" (0x001D) represents X25519. <del> OPEN ISSUE: Should we have a registry of well-known profiles? </del> 5. WARNING: This document is effectively brand new and has seen no

Discussion:
This change also reserves short profile IDs for "well-known" use. Fixes URL
Can we please try to resolve this question soon to unblock implementation?
NAME NAME Any objection to merging this?
The template says it's an integer (in what range?), but the ClientHello says it's 0-255 bytes. I think it's probably easiest to say it's a string of 0-255 bytes, with the empty string reserved to mean "no template". I guess if you want to get fancy you could reserve all 1-4 byte strings.
Agreed. If you want to send a PR, I wouldn't object.
This LGTM.
Change:
1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by <del> the sequence number of the received packet's DCID over that path (path identifier type 0x00), hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path (path identifier type 0x00) as path identifier, which </del> <ins> the sequence number of the received packet's DCID over that path, hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path as path identifier, which </ins> corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path.

Discussion:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
From PR by NAME
Looks good to me
Change:
dictionary with one or two further values that identify the IdP, as described in sec.idp-uri. <ins> An identity assertion as defined in this document relies on the value of "a=fingerprint" attributes, but this does not preclude the definition of alternative means of binding an assertion to the identity of a peer. </ins> The semantics of multiple identity attributes are undefined. Implementations SHOULD only include a single identity attribute in an offer and relying parties MAY elect to ignore all but the first

Discussion:
This currently uses the fingerprint, but that's just this version.
I am ok with this scope, and to allow other means to be defined in future. However, as the whole document is based on the usage of fingerprints for assertion, I think this scope should be defined in the beginning of the document, e.g., in a separate "Scope" section and/or in the Introduction. Related to that, the document references the W3C API between the user and the IdP. It would be good to say that other APIs can also be used, but is outside the scope of this document.
Change:
the individual messages separate and for providing length information. <del> The CoAP over TCP/TLS message format is very similar to the format </del> <ins> The CoAP over TCP message format is very similar to the format </ins> specified for CoAP over UDP.  The differences are as follows: Since the underlying TCP connection provides retransmissions and

Discussion:
I'm finding "CoAP over protocol" to be too verbose - especially in text that references or compares multiple protocol bindings. Can we agree on a shorthand? CoAP protocol such as CoAP UDP, CoAP TCP/TLS, CoAP WebSockets CoAP+protocol such as CoAP+UDP, CoAP+TCP/TLS, CoAP+WebSockets
The URI scheme component provides a reasonably good shorthand form to reflect the protocol bindings and the "Terminology" section could perhaps reflect that? It would be approximately lead to something like the following text: In this document, references to the various transport bindings for conveying CoAP messages adopt the following abbreviations: CoAP+TCP refers to CoAP over TCP, and CoAP+WS refers to CoAP over WebSockets. Using "CoAPS+" instead of "CoAP+" implies the use of their corresponding TLS-based secure counterparts. CoAP and CoAPS refer to CoAP over UDP and CoAP over DTLS, respectively.
Change:
is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS <del> extensions RFC6891 in the request. </del> <ins> options RFC6891 in the request. </ins> The media type is "application/dns-udpwireformat".

Discussion:
NAME my previous (deleted now) comment was in error in case you get a copy of that in email. sorry - git skillz failure on my part.
Change:
4.2.1. The configuration agent selects an arbitrary set of bits of the <del> server connection ID (SCID) that it will use to route to a given server, called the "routing bits".  The number of bits MUST have enough entropy to have a different code point for each server, and SHOULD have enough entropy so that there are many codepoints for each </del> <ins> server connection ID that it will use to route to a given server, called the "routing bits".  The number of bits MUST have enough entropy to have a different code point for each server, and SHOULD have enough entropy so that there are many codepoints for each </ins> server. The configuration agent MUST NOT select a routing mask with more than

Discussion:
Server CID will collide with Source CID.
This is often used to mean Source Connection ID in other contexts. A collision here is likely to cause confusion.
Recommended name? SCCID?
I think it might just be best to call it the "Server CID" any other abbreviated term will get confused IMO.
"Server CID" doesn't seem to fit well with "Stream Cipher Connection ID"
So SCID didn't mean "Server Connection ID"? There is definitely confusion here. I'd just recommend not abbreviating anything more than CID.
I guess this proves MT's point. "STream Cipher Connection ID" (just like PCID, OCID, BCID)
Looking again, the document never uses any acronym for 'stream cipher connection ID', so there's no issue there. This is just about 'S' meaning "source" or "server".
Change:
Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included, the previous last lifetime set on a previous update or the original <del> registration (falling back to 86400) SHOULD be used. </del> <ins> registration (falling back to 90000) SHOULD be used. </ins> Context (optional).  This parameter updates the context established in the original registration to a new value.  If

Discussion:
This is easier to to satisfy with a "once per day" update, a nice round number, and still over 9000. Closes: URL
I think that the default value of lt should be modified so that it is slightly greater than one day. If it is one day then a cron job which starts at midnight everyday could potentially end up not acting in time to renew rather than re-register an item. Given that a post to the resource adds the value of lt to the current time, there would be no drift in the expiration time.