jiebi/CodeConvo huggingface dataset:
Code change:
External Commits work like regular Commits, with a few differences: <del> External Commits MUST reference an Add Proposal that adds the issuing new member to the group </del> <ins> The proposals included by value in an External Commit MUST meet the following conditions: There MUST be a single Add proposal that adds the new issuing new member to the group There MUST be a single ExternalInit proposal There MUST NOT be any Update proposals If a Remove proposal is present, then the "credential" and "endpoint_id" of the removed leaf MUST be the same as the corresponding values in the Add KeyPackage. The proposals included by reference in an External Commit MUST meet the following conditions: There MUST NOT be any ExternalInit proposals </ins> External Commits MUST contain a "path" field (and is therefore a "full" Commit)

Related discussion:
text: Of course, that position would entail accepting that compromise of signature keys would be sufficient to impersonate the user, but that doesn't seem all that surprising, at least to me. So this seems like a question of group policy to me. Either the group requires ReInit PSKs on resync (and you can't recover from all-but-signature-key state loss), or it doesn't (and signature keys are the last resort). This can be documented in the Security Considerations, in a new PR. As far as , I think it's probably still worth adding the precision, but I would change the PSK part to MAY if not remove it entirely.
There is also a practical issue with using PSKs to prove past membership, in that if there have been joins since Alice lost state, the new joiners won't have the PSK. This is of course a general issue with the proof-of-past-membership PSK, but it is particularly salient here.
Code change:
The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY <del> only contain local candidates (or even an empty list of candidates). </del> <ins> only contain local candidates (or even an empty list of candidates) as per RFC8863. </ins> In order to simplify the protocol, there is no support for exchanging gathered trickle candidates from Media Server ICE candidates once the

Related discussion:
text: NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.
Code change:
The compressed form, using the byte alignment option of EXI, for the above XML is the following: <del> A small temperature sensor devices that only generates this one EXI </del> <ins> A small temperature sensor device that only generates this one EXI </ins> file does not really need an full EXI implementation.  It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID, and replacing the

Related discussion:
text: Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)
Code change:
This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry <del> established in HTTP3. </del> <ins> established in RFC9114. </ins> 8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry <del> established in HTTP3. </del> <ins> established in RFC9114. </ins>

Related discussion:
text: These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.
Code change:
the GroupContext. This extension lists the extensions and proposal types that must be <del> supported by all members of the group.  For new members, it is enforced by existing members during the application of Add commits. Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires capabilities not supported by all current members. </del> <ins> supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in RequiredCapabilities in order to be safely used. For new members, support for required capabilities is enforced by existing members during the application of Add commits.  Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires non- default capabilities not supported by all current members. </ins> 10.2.

Related discussion:
text: It might be useful to distinguish between basic (MTI) ones like Add, Remove, etc. and consider some optional such as ExternalInit or AppAck. Relatedly, should the extension in the KeyPackage list all the Spec proposals/extensions, too? Are they invalid if they do or if they don't? We might want to discuss the difference between RC and a potential group policy. The way I understand it, RC is not meant to be an allow list or a block list, but instead should specify a minimum requirement for all clients in the group. A question here would be: If it's not in the RC, but everyone's capabilities support it, can I use/send it?
Reacting to Konrad's points here: It seems like to to be sure, you always need to check. RC just helps ensure that the check will produce the right answer. I would propose the answer to this be "Yes, the proposals/extensions in the spec are MTI" If the answer to the prior question is as I propose, then you don't need to list spec proposals/extensions in Capabilities The difference between RC and checking everyone supports it is whether we expect it to be supported in the future. For Proposals, that might not matter; for GroupContext extensions, it matters more. It also seems like there's a fair argument that RequiredCapabilities should just be removed from the spec and replaced by some application-layer coordinated policy. I would be OK with that. To NAME point about mandatory extensions -- I would probably be OK with converting mandatory extensions to fields, especially with the better division of labor proposed in .
I kind of like the idea of RequiredCapabilities because it enforces the proper checks lower down. Application layer would need to proxy packets via a middleware type of layer which could potentially be messy.
Discussion on working call: Agreement to not list in-spec capabilities in RC/Capabilities, so all those things are MTI
Code change:
Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in <del> the same Connection Group. </del> <ins> the same Connection Group.  See priority-in-taps. </ins> 7.1.4.

Related discussion:
text: (well, the priority framework is still confusing, this PR makes it clear that that is intentional, and why)
Martin (I think) said that he'd check this offline after the Sep 11 interim.
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
I'm not sure the priority framework really fits together. Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5 allows the application to decide what happens. Meanwhile message priority suggests a strict priority-based scheduler. Meanwhile, in sec 8.1.3.2 "Note that this property is not a per-message override of the connection Priority - see Section 7.1.3. Both Priority properties may interact, but can be used independently and be realized by different mechanisms." At the risk of overindexing on a partly-baked draft in httpbis, how would I implement strict priority of HTTP/3 streams over a taps API that implements QUIC? Would I need to request strict priority in both connection priority and message priority? Or I guess connection priority would be sufficient?
We seem comfortable with the mechanisms in the API, but we should have more text connecting the various sections explaining priority.
My comment concerned "7.1.3. Priority (Connection)", my thought was this just influences the sender-side to control queuing within a connection group.
Code change:
Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in <del> the same Connection Group. </del> <ins> the same Connection Group.  See priority-in-taps. </ins> 7.1.4.

Related discussion:
text: If so, if it worth calling this property "Group Priority" and explain this is sender-side?
I find the priority framework perhaps overspecified at the connection level and underspecified at the message level, with the interaction between the two left explicitly unstated. I would almost rather see the priority type and meaning left completely implementation-specific; otherwise, my suspicion is that someone will write an application using numeric priorities, declare victory when it works fine on one platform, and not understand that the behavior is not universal. In general, I think if TAPS is going to produce a consistent, easily-understandable, and portable API, it needs to stick to easily-understood abstractions. Message-level priority is sort of like the TCP URG mechanism (though better specified and more useful, for sure), but I'm thinking urgent messages sent explicitly out-of-band (e.g., new Connection) with implementation-specific QoS will produce more consistent, predictable, and understandable outcomes in the pessimal case.
Ok for me (and thanks for doing this!)Some nits, but I believe this addresses my concerns in the issue.
Code change:
4. <del> This specification introduces two extensions to the SUIT envelope and the manifest structure, as motivated in arch. The SUIT envelope is enhanced with a key exchange payload, which is carried inside the suit-protection-wrappers parameter, see envelope- fig.  One or multiple SUIT_Encryption_Info payload(s) are carried within the suit-protection-wrappers parameter.  The content of the SUIT_Encryption_Info payload is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the suit-protection-wrappers parameter MUST be included in the envelope. The manifest is extended with a CEK verification parameter (called suit-cek-verification), see manifest-fig.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek- verification. </del> <ins> This specification introduces two extensions to the SUIT_Parameters, as motivated in arch. The SUIT manifest is enhanced with a key exchange payload, which is carried within the suit-directive-override-parameters or suit- directive-set-parameters for each encrypted payload.  One SUIT_Encryption_Info is carried with suit-parameter-encryption-info, see parameter-fig.  The content of the SUIT_Encryption_Info is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the SUIT_Encryption_Info parameter MUST be included in the SUIT_Directive. A CEK verification parameter (called suit-parameter-cek- verification), see parameter-fig, also extends the manifest.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek-verification. </ins> 5.

Related discussion:
text: Encryption of the plaintext is accomplished with conventional symmetric key cryptography. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTMLized version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
Code change:
MUST be at least 8 octets and no more than 16 octets.  The nonce length and server ID length MUST sum to 19 or fewer octets. <del> 4.3.2. </del> <ins> 4.2.2. </ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary

Related discussion:
text: by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.
Code change:
identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non- <del> constrained example of such mechanisms.  Connection identifiers SHOULD be unpredictable.  Using the same identifier several times is not a problem as long as it is chosen randomly.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </del> <ins> constrained example of such mechanisms.  Connection identifiers can e.g., be chosen randomly among the set of unused 1-byte connection identifiers.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </ins> 8.6.

Related discussion:
text: Suggestion to clarify and maybe give example of randomness and unpredictability. The SHOULD should probably be removed. Unclear if 1 byte identifiers can ever by unpredictable.
Closing this as approved by Marco.
Looks good to me. NAME ?
Code change:
sends the "split" flag as described in request-token-single. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del> <ins> include the "split" flag. </ins> [[ See issue #69 [17] ]]

Related discussion:
text: URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.
Code change:
properties outlined above.  The attack violates the same session keys property, as "A" and "B" have each completed a session, ostensibly with each other, and yet do not agree on the session key.  If "A" <del> does not send a key share, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </del> <ins> does not send a key share extension, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  Since the attacker has knowledge of all of the messages and their content, the nonce in the handshake does not prevent the attacker from computing the full key schedule.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </ins> 4. <del> Given the desired security goals from sec-properties, applications which make use of external PSKs MUST adhere to the following requirements: </del> <ins> To achieve the security goals from sec-properties when the external PSK will not be combined with a pairwise secret value, applications MUST use external PSKs that adhere to the following requirements: </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a

Related discussion:
text: Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!
Code change:
TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them.  Clients SHOULD NOT use <del> a session ticket or token from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. </del> <ins> a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, or vice versa. </ins> Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version.  A

Related discussion:
text: , , , , , .
Just a style thing (and something we should try an capture in a QUIC style guide).
There a bit of inconsistency through the document. Personally I prefer the QUIC version N style.
is there a missing word here?
Nope, extra word, thanks
I find this awkward to read in isolation, it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change. A clearer alternative could be "All version 2 Long Packet Types are different: Initial: 0b01 0-RTT: 0b10 Handshake 0b11 Retry: 0b00
Starting with This might be a matter of style but to me the term "changes" imply that you're modifying the original, not creating something new. How about we term these as differences instead? The the opening paragraph of Section 3 could be something like "QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ], ], and ]. However, the following differences apply in version 2."
This might have been important earlier in the document lifetime but it seems to stick out now.
This could be misread to imply the salt is universally known and universally applicable, which I don't think is your intention. In fact, I find the construction of this entire paragraph a bit awkward. Can we rephrase this for better clarity? Something like "In QUIC version 1, Initial packets are encrypted with the version-specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Clent Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the 1 key derivation and packet formats."
Couple of nits but otherwise LGTM
Code change:
interaction models in general, the following set of prerequisites MUST be in place to support the implementation of interaction models: <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity, used as proof of identity. </del> <ins> An Authentication Secret MUST be available exclusively to an Attesting Environment of an Attester. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence.  The Authentication Secret MUST be established before RATS can take place. A statement about a distinguishable Attester made by an Endorser. </ins> The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. <del> An Attester Identity MAY be a unique identity, MAY be included in a zero-knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </del> <ins> An Attester Identity MAY be an Authentication Secret which is available exclusively to one of the Attesting Environments of an Attester.  It MAY be a unique identity, MAY be included in a zero- knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </ins> Attestation Evidence MUST be authentic. In order to provide proofs of authenticity, Attestation Evidence SHOULD be cryptographically associated with an identity document <del> (e.g. an PKIX certificate or trusted key material, or a randomized DAA credential DAA), or SHOULD include a correct and unambiguous and stable reference to an accessible identity document. An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence.  The Authentication Secret MUST be established before RATS can take place. </del> <ins> (e.g., a PKIX certificate or trusted key material, or a randomized DAA credential DAA), or SHOULD include a correct, unambiguous and stable reference to an accessible identity document. </ins> Evidence MUST include an indicator about its freshness that can be understood by a Verifier.  Analogously, interaction models MUST

Related discussion:
text: Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan