jiebi/CodeConvo huggingface dataset:
Code change:
_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

Related discussion:
text: Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have?
Code change:
_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

Related discussion:
text: 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: 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. Comment > Does the Authentication Secret represent the identity of the Attesting Environment?
Code change:
_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

Related discussion:
text: Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation.
Code change:
_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

Related discussion:
text: Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. 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.
Code change:
_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

Related discussion:
text: 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
Code change:
4.2.4. The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a <del> server push prior to the push stream being created.  The CANCEL_PUSH </del> <ins> server push prior to the push stream being received.  The CANCEL_PUSH </ins> frame identifies a server push by Push ID (see frame-push-promise), encoded as a variable-length integer.

Related discussion:
text: Not sure if this is enough, but it enacts Brad's suggested fix.
Yup, that's what I had in mind.
Why is this limited to being prior to the push stream being created, given that you specify how the server handles it if it has created the stream.
I don't read this as saying that you have to avoid it. The point is that you also have to reset/STOPSENDING on the stream if it exists, so there is no real point to using CANCELPUSH in addition.
Sounds like the intent is that CANCELPUSH should be used between the client receiving a PUSHPROMISE and before receiving the stream (i.e. when it is ambiguous as to whether the stream has been created by the server from the clients perspective). I think replacing "created" with "received" would make this more clear.
Code change:
2.1. This document uses the terminology and concepts established in the <del> DetNet architecture RFC8655 and I-D.ietf-detnet-data-plane-framework, and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with these documents and their terminology. </del> <ins> DetNet architecture RFC8655 and RFC8938, and I-D.ietf-detnet-mpls. The reader is assumed to be familiar with these documents and their terminology. </ins> 2.2.

Related discussion:
text: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)
Code change:
record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set <del> using the EDNS(0) Update Lease option I-D.sekar-dns-ul. </del> <ins> using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease. </ins> The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the

Related discussion:
text: Update the draft number, date, and change draft-sekar-ul to draft-ietf-dnssd-update-lease.
Code change:
set to "webtransport", the HTTP/3 server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 <del> (Section 15.5.4, HTTP).  If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP.  The WebTransport server MUST verify the "Origin" header to </del> <ins> (Section 15.5.5 of HTTP).  When the request contains the "Origin" header, the WebTransport server MUST verify the "Origin" header to </ins> ensure that the specified origin is allowed to access the server in <del> question. </del> <ins> question.  If the verification fails, the WebTransport server SHOULD reply with status code 403 (Section 15.5.4 of HTTP).  If all checks pass, the WebTransport server MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP. </ins> From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's

Related discussion:
text: In URL, it was suggested that 403 status code should be used when Origin verification fails.
Thank you for suggestions! Applied.
Thank you for reviews! If this looks good can someone merge this?
Looking good, thank you! Added a few suggestions to cause it to generate links to the actual sections referenced, even if it makes it a little more repetitive.Approved modulo one small change
Code change:
its own, but needs a framing protocol on top to determine message boundaries. <del> Both stacks MUST offer the transport services that are required by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </del> <ins> Both stacks MUST offer the transport services that are requested by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </ins> using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack

Related discussion:
text: Closed
I just read Arch and have the following NiTs which I think we should address: /Listeners by default register with multiple paths/ ought this to be: /Listeners, by default, register with multiple paths/ /A Framer is a data translation layer that can be added to a Connection to define how application-level Messages are transmitted over a transport protocol. / I think this should be (because I don’t think they are protocol specific) /A Framer is a data translation layer that can be added to a Connection to define how application-level Messages are transmitted over the transport service. / /to retransmit in the event of packet loss,/ better to avoid event here :-) /to retransmit when there is packet loss,/
I am just gonna add a few more nits here: The Listener object in figure 4 is a bit awkward, it appears as if the Listen() call appears out of thin air while per the API it gets called on the preconnection object like Initiate() and Rendezvous(). In section 4.1.1, there are 5 references to section 4.1.2, is it really necessary to have that many? Point 2 in section 4.2.3 only talks about required transport services, the same should probably be said about prohibited services, i.e. "both protocol stacks MUST NOT offer transport services prohibited by the application"
Let me add to this: Section 1: print send() and recv() in fixed-with font [HTML/XML issue only] Section 2 - Figure 1: socket() [with the brackets] looks odd in the figure title
NAME I fear framers may be specific to the underlaying protocol, e.g., for SIP slicing messages out of TCP stream whereby doing nothing for SCTP and UDP
In relation to frames I think I only asked to add /service/ instead of protocol... I don't understand how Phil's comment reacts to that
NAME I think protocol is correct here and would not change the sentence.
OK - so I think you are saying the framer depends only on the specific next protocol, rather than upon the transport service that was offered? - It is still not clear to me that this is correct.
NAME that is a fairly good question… The behaviour of the framer defiantly depends on the transport service provided (which may be a subset or superset of the transport service requested).
Code change:
its own, but needs a framing protocol on top to determine message boundaries. <del> Both stacks MUST offer the transport services that are required by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </del> <ins> Both stacks MUST offer the transport services that are requested by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack </ins> using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack

Related discussion:
text: A framer needs to support all possible outcomes of the transport services requested It may optimize based on the protocols it actually finds, e.g., turn into a no-op with the transport preserves message boundaries. Whether the next protocol is a sufficient representation of this is unclear to me. Maybe not, if one thinks of supporting arbitrarily large messages and UDP over IPv6 with and without fragmentation…
LGTM, thanks!
Code change:
setting, HSMs and secure enclaves can be used to protect signature keys. <ins> 6.6. Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] analyze the ratcheting tree as the sub-protocol of MLS that facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK19] analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 7. <ins> ACDT19: https://eprint.iacr.org/2019/1189 ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACJM20: https://eprint.iacr.org/2020/752 AJM20: https://eprint.iacr.org/2020/1327 ACDT21: https://eprint.iacr.org/2021/1083 AHKM21: https://eprint.iacr.org/2021/1456 CHK19: https://eprint.iacr.org/2021/137 BCK21: https://eprint.iacr.org/2021/137 BBR18: https://hal.inria.fr/hal-02425247 BBN19: https://hal.laas.fr/INRIA/hal-02425229 8. </ins> This document makes no requests of IANA.

Related discussion:
text: This PR adds a short paragraph referencing the various academic works that has gone into MLS. The references to the various works still need to be cleaned up, which I will do once the list is complete. In particular, each reference needs to be checked for correctness (eprint version vs. publicized version) and then included as informal reference in the yaml header of the document.
Is there another RFC you can point to that links academic papers on the protocol? I'd expect TLS 1.3 to be a good example of this, but I don't see them do this. The references should be cited properly if we do include it (ie, added as citations at the top of the file)
The references are in the appendices. For instance URL The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
TLS 1.3 as cited by NAME was indeed the inspiration for this. The idea was to just have a small paragraph to point the reader in the right direction and then have the full bibliographic entry in the "Informal References" section. As noted above, I intend to properly format all the references once we agree on what references to include, as formatting them into the right yaml is a bit of a pain.
Thanks Konrad!