jiebi/CodeConvo huggingface dataset:
Change:
2.1.2. <del> A dynamic table entry is considered blocking and cannot be evicted until its insertion has been acknowledged and there are no outstanding unacknowledged references to the entry.  In particular, a dynamic table entry that has never been referenced can still be blocking. An encoder MUST NOT insert an entry into the dynamic table (or duplicate an existing entry) if doing so would evict a blocking entry.  In order to avoid this, an encoder that uses the dynamic table has to keep track of blocking entries. A blocking entry is unrelated to a blocked stream, see blocked- streams. </del> <ins> Inserting entries into the dynamic table might not be possible if the table contains entries which cannot be evicted. A dynamic table entry cannot be evicted immediately after insertion, even if it has never been referenced.  Once the insertion of a dynamic table entry has been acknowledged and there are no outstanding unacknowledged references to the entry, the entry becomes evictable. If the dynamic table does not contain enough room for a new entry without evicting other entries, and the entries which would be evicted are not evictable, the encoder MUST NOT insert that entry into the dynamic table (including duplicates of existing entries). In order to avoid this, an encoder that uses the dynamic table has to keep track of whether each entry is currently evictable or not. </ins> 2.1.2.1.

Discussion:
Acting on NAME suggestion.
Thank you, this greatly improves clarity.
Technically, all reviews request rather than require. Those are good suggestions, though.
Incorporated, though the parenthetical reads even more awkwardly now. Suggestions on improving that (or consensus to drop it) are welcome.
This review suggests changes, not "requires" them.
Change:
to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the application immediately via <del> the ICE candidate callback.  If the pool becomes depleted, either </del> <ins> the ICE candidate event.  If the pool becomes depleted, either </ins> because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual.

Discussion:
Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM
Change:
An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations <del> might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Another example is that of a Composite Devices: Composite Devices are defined below, and are inherently composed of multiple nested environments. </del> <ins> might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositeattester.  Other examples may exist, and the examples discussed could even be combined into even more complex implementations. </ins> Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be <del> represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </del> <ins> represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </ins> 4.2.

Discussion:
Provide forward references Use "measure" in English text Signed-off-by: Dave Thaler
(I had to do this right away before I forgot what I was suggesting during the meeting :)
Change:
K_3 and IV_3 are defined in <del> PLAINTEXT_3 = ( ? PAD, ID_CRED_I / bstr / -24..23, </del> <ins> PLAINTEXT_3 = ( ? PAD_3, ID_CRED_I / bstr / -24..23, </ins> Signature_or_MAC_3, ? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e.,

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
By default, the Relying Party does not believe the Attester to be compliant.  Upon receipt of an authentic Attestation Result and given <del> the Appraisal Policy for Attestation Results is satisfied, then the </del> <ins> the Appraisal Policy for Attestation Results is satisfied, the </ins> Attester is allowed to perform the prescribed actions or access.  The <del> simplest such Appraisal Policy might authorize granting the Attester </del> <ins> simplest such appraisal policy might authorize granting the Attester </ins> full access or control over the resources guarded by the Relying <del> Party.  A more complex Appraisal Policy might involve using the </del> <ins> Party.  A more complex appraisal policy might involve using the </ins> information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result.

Discussion:
This is the portion of the complete review that contains minor/editorial changes aggregated in a single PR and various commits as discussed in the last editor meeting.
Are you sure that making Composite Device a term isn't a better idea?
I agree with that. There are also some other terms that I would capitalize. But this is the editorial part of the changes so I stuck with the groups consensus. Could you open an issue on "terms you want to capitalize"?
When I ask github to render the diff, it says that it can not. ("Oh my") it says. I wonder if there is an error in the markdown?