jiebi/CodeConvo huggingface dataset:
Change:
6. <del> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] </del> <ins> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code.  Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar capablities.  Usually application error codes are defined to be applicabile to all three frames. Alternatively, a QUIC connection will be silently closed by each endpoint separately after an idle timeout.  The idle timeout is announce for each endpoint during connection established and should be accessible by the application.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. </ins> 7.

Discussion:
This section was still empty so far. This PR also address issue .
This is related to quicwg/base-drafts and depends on the outcome there.
PR now indicated that the idle timeout could be exposed to the application. However, we should probably say a bit more what to do with it. I guess the minimum would be to say that the keep-alive frequency needs to be clearly smaller than the idle timeout, e.g. half the timeout. Is there anything more we could say? NAME NAME any thoughts? Or text you can provide?
PR provides some more guidance now but it still doesn't discuss suitable value or ranges. What values are used in current implementations? Should we say more?
See also PR
merged
This is good, modulo typos (all edits as suggestions)
Change:
Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or appraisal policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </del> <ins> Verifier. As discusssed in rpowner-trust, authentication or attestation in both directions might be needed, in which case typically one side's identity or Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence.  See privacy- considerations for more discussion. </ins> 8.

Discussion:
1) Avoid the term "mutual attestation" 2) Add reference to CCC whitepaper for discussion of anonymous attestation Signed-off-by: Dave Thaler
Does this term (Mutual Authentication) need to be defined? Aren’t there lots of cases where mutual attestation might be employed?
We have not defined Mutual Authentication, why would Mutual Attestation be any different?
Could there be a reference to this other document, C3 document. I don’t know what it means, but all the cases here seem to ultimately rely on a unitary Verifier/Relying-Party somewhere in the chain. Maybe that’s not true… if the verifier and relying party trust each other by fiat, the roles need not be combined.
It means this: Say you have devices A (normally an Attester) and V (normally a Verifier) and RP (normally a Relying Party). A can say it won't send Evidence to V unless V first attests to A. Thus, A starts by acting as a Relying Party where V is the Attester. If A devices that V is trustworthy, then A can start sending sensitive Evidence to V. Note this does not require anywhere have a combined Verifier/Relying Party.
I can see how: "Verifier/Relying Party" looks misleading here Dave illustrated well that this text is not about a "unitary Verifier/Relying-Party" this is related to the current mutual authentication/attestation discussion that recently emerged I'll try to pitch this issues in the next meeting so we can deal with it in the same swoop as mutual authentication. Personally, I'd simply leave the text as is.
reference
closed with email: URL
Closing since Michael's comment above says "closed with email" but didn't actually close the issue EMAIL wrote: The design team closed a few remaining issues and pull requests. Two pull requests turned out to fix the same text, so we needed to be sure we really liked the text we chose. On issue , wontfix: URL -- Attester We discussed the issue of how the RP trusts that the Verifier is operating correctly. (Who Verifies the Verifier?) This does not lead to architecting a "unitary Verifier/Relying-Party somewhere in the chain", as the roles can still be split out.

When we dealt with the "mutual attestation" issue, in URL we changed text that has relevance to this issue. We have no issues open. No pull requests. If the Shepherd hasn't already started, then they should please start. Michael Richardson . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
Change:
In JSON, this value is represented as "true" or "false". <ins> TODO: It seems like there was an intent to elide the "Certificate.certificate_request_context" field, but this is not stated explicitly anywhere. </ins> 2.1.1.8. Value: a single "CTLSExtensionTemplate" struct:

Discussion:
The example did not account for the record layer, and seemed to overlook some other details as well.
CTLSClientPlaintext and CTLSServerPlaintext seem to be included in the example exchange but CTLSCiphertext seems to be missing. My understanding is that ServerFlight and ClientFlight are sent over CTLSCiphertext which would add a mimimum of 2 * 11 bytes. It is not explained why the signature is 64 bytes. In TLS 1.3, my understanding is that ecdsasecp256r1sha256 is variable length 12-76 bytes with an average length close to 75 bytes. Changing ecdsasecp256r1sha256 to ed25519 (or ecdsasecp256r1sha256_compact) would make it 64 bytes. The introduction promises an example PSK handshake, but that is missing.
NAME Please review , which attempts to fix the example as you've described.
Change:
3.2.2. <del> The Key Distributor, which may be collocated with an endpoint or exist standalone, is responsible for providing key information to endpoints for both end-to-end and hop-by-hop security and for providing key information to Media Distributors for the hop-by-hop security. </del> <ins> The Key Distributor, which may be colocated with an endpoint or exist standalone, is responsible for providing key information to endpoints for both end-to-end and hop-by-hop security and for providing key information to Media Distributors for the hop-by-hop security. </ins> Interaction between the Key Distributor and the call processing function is necessary to for proper conference-to-endpoint mappings.

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.
Change:
From the "joiner_secret" in the decrypted GroupSecrets object and the PSKs specified in the "GroupSecrets", derive the <del> "member_secret" and using that the "welcome_secret", "welcome_key", and "welcome_nonce".  Use the key and nonce to decrypt the "encrypted_group_info" field. </del> <ins> "welcome_secret" and using that the "welcome_key" and "welcome_nonce".  Use the key and nonce to decrypt the "encrypted_group_info" field. </ins> Verify the signature on the GroupInfo object.  The signature input comprises all of the fields in the GroupInfo object except the

Discussion:
This is a small suggestion to move the definition of the to the end of the first Extract-Expand (KDF) cycle of the [key schedule]. This makes more sense from a cryptographic perspective as we would not be using anything from the middle of a KDF cycle. A related suggestion is to remove the from the document. I removed it from the key schedule, removed all the mentions to forget it as soon as possible and updated the description of deriving the and from the [welcoming new members] section. [key schedule]: URL [welcoming new members]: URL
Thanks for the quick fix, NAME !
Change:
Using the GET method is friendlier to many HTTP cache implementations. <del> The DNS API client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client </del> <ins> The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client </ins> MUST be prepared to process "application/dns-udpwireformat" dnswire <del> responses but MAY process any other type it receives. </del> <ins> responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat,

Discussion:
The fact that an HTTP server can provide a response in the format of its choice was not well understood by DNS people. This motivates the MTI format for servers.
On 2018-03-25, NAME sent the following to the list: At the meeting in London last week, we asked the room for opinions on two topics: Should we have a content-type that is Mandatory to Implement? Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. If you would like to voice a dissenting opinion on either point, please reply on this list. Otherwise, the chairs will regard these decisions as the group's consensus.
See PR
I think most of this can be handled by the MTI PR. But I will just make a tiny clarification indicating that the server is really able to return whatever it needs to.
Change:
9.2. <del> The MP_ACK frame (types TBD-00 and TBD-01; experiments use </del> <ins> The ACK_MP frame (types TBD-00 and TBD-01; experiments use </ins> 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that <del> were sent on different paths.  If the frame type is TBD-01, MP_ACK </del> <ins> were sent on different paths.  If the frame type is TBD-01, ACK_MP </ins> frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point.

Discussion:
Should we trigger an connection closure with a MPCONNECTIONERROR in the case an endpoint receives an ACK_MP frame acknowledging packets on a non-existing packet number space ID?
Yes. I just submitted PR for this issue.
PR merged.
LGTM.
Change:
is a principle, 2^b-th root of unity (i.e., g^(s*2^b) = 1), where g is the generator of the multiplicative subgroup.  This fact allows us to quickly evaluate and interpolate polynomials at <del> 2^a-th roots of unity for any 1 <= a <= b.  Note that b imposes n </del> <ins> 2^a-th roots of unity for any 1 <= a <= b.  Note that b imposes an </ins> upper bound on the size of proofs, so it should be large enough to accommodate all foreseeable use cases.  Something like b >= 20 is probably good enough.

Discussion:
Removes the old Prio text, which by now is out-of-date. Addresses by changing the criteria.
The current criteria: Criterion (3) doesn't seem that important to me any more. I've yet to think of a use case where we want to do inversion in a validity circuit, or for which we don't have an alternative to FLT. In any case, we already can get pretty good performance with a more standard, generic algorithm: URL In addition to dropping (3), we should modify (2) by saying that needs to be large enough to accommodate the largest proofs we would ever generate. seems like a reasonable minimum. Finally, an important criterion to add would be to pick a field size that is as close as possible to a power of 2 without being larger. This helps to minimize the cost of rejection sampling when generating random field elements (see ).
Closing this since it's no longer relevant to this document. (It will be relevant to URL, however.)
Change:
Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. <del> A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </del> <ins> A sender might use timers to detect loss of PMTU probe packets (Section 14 of QUIC-TRANSPORT).  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMU probes to avoid triggering such timers. </ins> 9.4.

Discussion:
originally created by NAME in URL (but not PR was created)
A sender might use timers to detect loss of PMTUD probe packets. A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. This seems also valuable for DPLPMTUD.
QUIC loss detection doesn't use timers to detect loss, it uses acknowledgement of subsequently sent packets. In RFC9000, we indicate that a timer is not necessary for DPLPMTUD. URL One could include an IMMEDIATE_ACK with a probe to speed up Path MTU, though I'm not sure if that's a useful optimization or not? It doesn't seem harmful, but I'm just not sure if we should comment on it. What do you think?
NAME it seems your commit didn't make it to a PR. Can you check that? Also does your commit address this issue fully (by adding a reference to RFC9000). To be honest, after your discussion it sounds to me that this sentence should rather be a MAY than a SHOULD (as it is currently written in the draft). However, no strong opinion from my side to change that.
Looks good as a concrete example of immediately acknowledging.
Change:
ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R. <del> The value of a COSE 'kid' parameter is a CBOR byte string.  For a more compact encoding, the CBOR map is replaced by a byte string, see the definitions of plaintext in asym-msg2-proc and asym-msg3-proc. To allow one-byte encodings of ID_CRED_x with key identifiers 'kid', the same representation used for EDHOC connection identifiers defined in bstr-repr MUST be applied. Examples: The CBOR map { 4 : h'FF' } is not encoded as 0xA10441FF but as the CBOR byte string h'FF', i.e., 0x41FF. The CBOR map { 4 : h'21' } is neither encoded as 0xA1044121, nor as the CBOR byte string h'21', i.e., 0x4121, but as the CBOR integer 0x21. </del> As stated in Section 3.1 of RFC9052, applications MUST NOT assume that 'kid' values are unique and several keys associated with a 'kid' may need to be checked before the correct one is found.  Applications

Discussion:
Clarification of the optimization of ID_CRED for 'kid',
Merging to include in -18
In , there is I would have expected this to be as per or have I missed something? There is a degree of ambiguity in ` is this refers to the byte string, not necessarily the subset integer equivalent, but the lake-traces would still appear to be wrong.
NAME That looks like a bug. As you can see further down in the same section: ( ? PAD2, IDCREDR / bstr / -24..23, SignatureorMAC2, ? EAD2 ) 32 48 d0 d1 a5 94 79 7d 0a af which is IDCREDR followed by 9 bytes CBOR encoding of SignatureorMAC2. We should also clarify to avoid the ambiguity. Thanks!
I removed the label so we don't forget to also clarify in the spec.
I was too quick making a change in -traces which I had to revert. The implementation is right (of course). So I made a clarification in -edhoc instead, see . Please review.
NAME PR is now merged. Let us know if you have any further comments.
Thanks for the update. When I have some spare time, I am doing a libcoap port. I have now got as far as doing Message_2 as per the traces.
Cool, keep us updated on the progress and if you are interested in interop-testing. Closing this issue then.
Change:
authenticated by the signature, or just present.  An example of a parameter about the content is the content type.  Examples of parameters about the signature would be the algorithm and key used to <del> create the signature, when the signature was created, and counter signatures. </del> <ins> create the signature and counter signatures. </ins> When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response <del> and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3 or higher, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS.  This document only lists additional and different requirements, restrictions, and processing compared to RFC8446 and RFC5216. </del> <ins> and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS.  This document only lists additional and different requirements, restrictions, and processing compared to RFC8446 and RFC5216. </ins> 2.1.1.

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
The "ServerConfig" struct describes and maintains the underlying configuration that is used by the server. <del> The "SecretKey" and "PublicKey" types are just wrappers around byte </del> <ins> The "PrivateKey" and "PublicKey" types are just wrappers around byte </ins> arrays. 3.1.3.

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
A content negotiation mechanism where the server selects a representation based on the expressed preference of the client. <del> For example, in an IoT application, a client could send a request </del> <ins> For example, an IoT application could send a request to a sensor </ins> with preferred media type "application/senml+json". A content negotiation mechanism where the client selects a

Discussion:
Note about client role and reference to architecture section for details.
+1 (if the newline in the definitions () still does render correctly...
How do you like your newlines cooked?
The definitions seem to render correctly. I'll merge this.
Change:
[[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]] <ins> 5.1. This specification establishes the GNAP Token Format Registry to define token formats. 5.1.1. 5.1.2. The table below contains the initial contents of the GNAP Token Format Registry. </ins> 6. [[ TBD: There are a lot of security considerations to add. ]]

Discussion:
Adds registry and discussion for access token formats and where they could be used in the protocol, particularly as part of discovery from the AS. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 99546a7caad92bf2495cb9416f5e4604f9fcc7c0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Section 3.1 mentions: A sub-section describing the structure of this list of token formats is currently missing.
In section 2. Access Token Formats, the text states: Token formats can be the topic of agreements between the AS and RS , if the AS has prior relationships with every RS. However, it should be mentioned that the access token format can also be negotiated. Add:
The negotiation is between the AS and RS, not the client. This spec is about negotiation between the AS and RS.
Change:
party software, then process the KeyPurposeId(s) as described below. <del> Each restriction on "Excluded KeyPurposeId" or "Permitted KeyPurposeId" is handled as described below. </del> This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document. </del> <ins> permit or prohibit combinations of KeyPurposeIds, instead of single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and "Permitted KeyPurposeId" exists, the relying party or the relying party software proresses each restriction on "Excluded KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId". </ins> "Excluded KeyPurposeId" is a KeyPurposeId which the relying party or the relying party software prohibits.  Examples of

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."