jiebi/CodeConvo huggingface dataset:
Change:
2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00) after processing at the message layer.  For Confirmable (CON), Non- Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. 2.3. </del> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the

Discussion:
Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).
Change:
Unlike most TLS extensions, placing the SNI value in an ECH extension is not interoperable with existing servers, which expect the value in <del> the existing cleartext extension.  Thus server operators SHOULD </del> <ins> the existing plaintext extension.  Thus server operators SHOULD </ins> ensure servers understand a given set of ECH keys before advertising them.  Additionally, servers SHOULD retain support for any previously-advertised keys for the duration of their validity

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
Both mechanisms are described in detail later in this document. <del> 2.1. OEM - Equipment manufacturer.  Operate the MASA. Network operator.  Operate the Owner Registrar.  Often operated by end owner (company), or by outsourced IT entity. </del> <ins> As depicted in architecture-figure, there are a number of parties involve in the process.  The Manufacturer, or Original Equipment Maker (OEM) builds the device, but also is expected to run the MASA, or arrange for it to exist. The network operator or enterprise is the intended owner of the new device: the pledge.  This could be the enterprise itself, or in many cases there is some outsourced IT department that might be involved. They operator the Registrar or EST Server.  They may operate the CA, or they may contract those services from another entity. Unlike in RFC8995 there is a potential additional party involved, the network integrator, who may operate the Cloud Registrar.  This is typically a value added reseller who works with the OEM to ship products with the right configuration to the owner.  For example, SIP telephones or other conferencing systems may be installed by this VAR, often shipped directly from a warehouse to the customer's remote office location.  The network integrator and manufacturer are aware of which devices have been shipped to the integrator through sales channel integrations, and so the manufacturer's Cloud Registrar is able to redirect the pledge through a chain of Cloud Registrars, as explained in redirect-response. </ins> <del> Network integrator.  They operate a Cloud Registrar. 2.2. </del> <ins> 2.1. </ins> The assumption is that the pledge already has network connectivity prior to connecting to the cloud registrar.  The pledge must have an

Discussion:
I find this section too telegraphic. Needs a bit more grammar...
Maybe we just delete this section completely NAME ?
I think we should eliminate the heading, but expand the content to better match the diagram.
I'm not convinced. In the rest of the doc, we never mention OEM or Network integrator. And Network operator is only mentioned again in secetion "Issues with Security of HTTP Redirect" I lean to delete completely, unless you have some explicit ideas and concepts you need to get across. FIne if you do - maybe include that in your abstract rewrite PR?
This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar).
No, this is a runon sentence. It is worth. Let me work on something for Friday.
Change:
waiting for the RO to authorize the request. The client instance request.  The client instance does not send <del> any interactions modes to the server, indicating that it does not </del> <ins> any interaction modes to the server, indicating that it does not </ins> expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using the request-user.

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
GroupContext for the current epoch, so that signatures are specific to a given group and epoch. <ins> [[OPEN ISSUE: group_id and epoch are duplicated in the TBS and in GroupContext.  Think about how to de-duplicate.]] </ins> The ciphertext field of the MLSCiphertext object is produced by supplying the inputs described below to the AEAD function specified by the ciphersuite in use.  The plaintext input contains content and

Discussion:
by special-casing external senders. Removing the GroupContext would allow me to take messages that user A sent in one instance of a group, and make it look like they're speaking in another group by re-encrypting the ciphertext.
Right now, the signature on an MLSPlaintext includes the GroupContext for the group. If we are going to allow Add proposals signed by the new member, then this will need to change, because the new member doesn't know the GroupContext. My preference would be to simply remove the GroupContext from the plaintext. The Group ID is already included, so copy/paste protection can be added that way. The other elements of the GroupContext effectively overlap with the Epoch that is already signed.
Haven't thought about this too deeply, but having the full GroupContext in MLSPlaintextTBS means that we know all the members agree on the state of the ratchet tree, the transcript, the extensions. Removing it means we would no longer have agreement on those, right?
We won't have confirmation of agreement as a result of signature verification. The question is whether that is necessary. If the MLSPlaintext was decrypted from an MLSCiphertext, for example, then the successful decryption of the MLSCiphertext implies agreement on all those things. I suppose you could also switch the signature input based on SenderType, but that seems messier.
I'm not so sure that decrypting an MLSCiphertext implies agreement, because the crypto is symmetric. A man-in-the-middle can re-encrypt but not re-sign.
Change:
an Attester.  Such trust might come by the Relying Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in the Verifier's <del> certificate chain. </del> <ins> certificate path.  Such trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. </ins> The Relying Party might implicitly trust a Verifier, such as in a Verifier/Relying Party combination where the Verifier and Relying

Discussion:
Also add a brief security considerations section, based on text from the TEEP architecture draft. Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
Change:
6. <del> PSK ciphersuites were first specified for TLS in 2005.  Now, PSKs are </del> <ins> PSK ciphersuites were first specified for TLS in 2005.  PSKs are now </ins> 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- <del> of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </del> <ins> of-band.  This section describes known use cases and provisioning processes for external PSKs with TLS. 6.1. This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and one client, have been used for authentication in TLS. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

Discussion:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.
Change:
This document defines the following extension code point. A client which supports this document SHALL send an empty <del> "delegated_credential" extension in its ClientHello. If the extension is present, the server MAY send a DelegatedCredential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent. When negotiating TLS 1.3, and using Delegated credentials, the server MUST send the DelegatedCredential as an extension in the CertificateEntry of its end-entity certificate.  When negotiating TLS 1.2, the DelegatedCredential MUST be sent as an extension in the ServerHello. The DelegatedCredential contains a signature from the public key in </del> <ins> "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client SHOULD abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. The delegated credential contains a signature from the public key in </ins> the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least

Discussion:
These came up when I implemented the extension in Go (URL) and I think would be useful to add to the standard.
looks good to me
Change:
interest in using GitHub and making a consensus call to determine if the proposed policy and use is acceptable. <del> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </del> <ins> Chairs SHOULD involve Area Directors in any decision to use GitHub, especially where substantive discussion of issues is permitted as described in mode-discuss. </ins> 3.1.

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
Any group member can impersonate any other group member. <del> If PSK with DH is used, then compromise of a group member that actively completes connections with other group members can read (and modify) traffic. </del> <ins> If PSK is combined with DH, then compromise of a group member that knows the resulting DH shared secret will enable the attacker to read (and modify) traffic. </ins> <del> If PSK without DH is used, then compromise of any group member allows the attacker to passively read (and modify) all traffic. If a group member is compromised, then the attacker can perform all of the above attacks. </del> <ins> If PSK is not combined with DH, then compromise of any group member allows the attacker to passively read (and actively modify) all traffic. </ins> Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described <del> below.  Note that this class of attack is not possible if each member uses the SNI extension RFC6066 and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity.  See Selfie for details. </del> <ins> below.  Note that a partial mitigiation against this class of attack is available: each group member includes the SNI extension RFC6066 and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity.  See Selfie for details. </ins> To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows:

Discussion:
This deals with many comments from the AD Evaluation. The comment on section 6.1 still needs to be resolved, and the NITS need to be addressed.
Chris's suggestions generally seem reasonable
Change:
The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del> <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 4.2.3.2. The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del> <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 5.

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 00127788e68e6777c3e674eb44e3a821cb54516e Inspect the deploy log: Browse the preview:
in 4.2.3.1 and 4.2.3.2, for base64 encoded URLs with no padding (+ by the way, we should explain what we mean by no padding and URL safe)
Base64 URL-safe encoding, with and without padding, is defined in RFC4648. URLsafe: URL Optional padding: URL
thanks exactly the links i needed
Change:
2. <del> The Captive Portal DHCP / RA Option informs the client that it may be </del> <ins> The Captive-Portal DHCP / RA Option informs the client that it may be </ins> behind a captive portal and provides the URI to access an API as defined by [draft-ietf-capport-api].  This is primarily intended to improve the user experience by showing the user the captive portal

Discussion:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)
Change:
Reordering Threshold value SHOULD send an immediate ACK when the gap between the smallest Unreported Missing packet and the Largest Unacked is greater than or equal to the Reordering Threshold value. <ins> Sending this additional ACK will reset the "max_ack_delay" timer and "Ack-Eliciting Threshold" counter as any ACK would do. </ins> In order to ensure timely loss detection, it is optimal to send a Reordering Threshold value of 1 less than the packet threshold used

Discussion:
This clarification is not necessarily needed but I think it would help me. Just a proposal...
Change:
4. The ACE framework is based on the OAuth 2.0 protocol interactions <del> using the /token and /introspect resources.  A client obtains an access token from an AS using /token and presents the token to an RS to gain access to a protected resource.  Alternatively, or additionally, the RS can use an obtained access token with the AS /introspect resource to get information about the state and content of the access token.  These interactions are shown in fig:protocolFlow.  An overview of various OAuth concepts is provided in oauth2Overview. </del> <ins> using the /token and /introspect endpoints.  A client obtains an access token from an AS using the /token endpoint and subsequently presents the access token to an RS to gain access to a protected resource.  The RS, after receiving an access token, may present it to the AS via the /introspect endpoint to get information about the state and content of the access token.  In other deployments the RS may process the access token locally without the need to contact an AS.  These interactions are shown in fig:protocolFlow.  An overview of various OAuth concepts is provided in oauth2Overview. </ins> The consent of the resource owner, for giving a client access to a protected resource, can be pre-configured authorization policies or

Discussion:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.
Change:
values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of <del> comparison. A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in An entity (typically an administrator), that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be used by a Relying Party An entity (typically an administrator), that is authorized to configure Appraisal Policy for Evidence in a Verifier </del> <ins> comparison.  Used By: Verifier; Produced By: Reference Value Provider. </ins> 5.

Discussion:
This reworks the pull request: using the latest text. Commit 1 - move all the text. Commit 2 - add produces/consumes. Commit 3 - move the text into categories. Reviewing the commits individually is probably better.
Please review NAME
Change:
URL-TBD <del> No transformation needed.  The </del> <ins> No transformation needed. </ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document, and replace URL-TBD with the URL assigned by IANA

Discussion:
Failure to synchronize between and . Also removes a stray word and some whitespace in the vicinity.
Also in the registries (and in the "Order Objects" section), is the authorizations property of an order object an array of strings (URLs) or an array of dictionaries (each of which contains status and URL parameters)?
NAME array of strings, since
Change:
5.2. <del> For example, assume a DNS API server is following this specification on origin https://dnsserver.example.net/ and the well-known path. The DNS API client chooses to send its requests in application/dns- udpwirefomat but indicates it can parse replies in that format or as a JSON-based content type. The examples uses HTTP/2 formatting from RFC7540. A query for the IN A records for "www.example.com" with recursion turned on using the GET method and a wireformat request would be: </del> <ins> These examples use HTTP/2 style formatting from RFC7540. For this example assume a DNS API server is following this specification on origin https://dnsserver.example.net/ and the well- known path.  The DNS API client chooses to send its requests in application/dns-udpwirefomat but indicates it can parse replies in that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </ins> The same DNS query, using the POST method would be:

Discussion:
proposed to close issue
NAME thanks
If it isn't then including it in an example might be unwise. Explicitly pointing out that it is currently fictitious might avoid confusion.
some typos