jiebi/CodeConvo huggingface dataset:
Change:
3.3. For each separate block-wise request operation, the client can choose <del> a Request-Tag value, or choose not to set a Request-Tag.  Starting a request operation matchable to a previous operation and even using the same Request-Tag value is called request tag recycling.  The absence of a Request-Tag option is viewed as a value distinct from all values with a single Request-Tag option set; starting a request operation matchable to a previous operation where neither has a Request-Tag option therefore constitutes request tag recycling just as well (also called "recycling the absent option"). Clients MUST NOT recycle a request tag unless the first operation has concluded.  What constitutes a concluded operation depends on the application, and is outlined individually in req-tag-applications. </del> <ins> a Request-Tag value, or choose not to set a Request-Tag.  It needs to be set to the same value (or unset) in all messages belonging to the same operation, as otherwise they are treated as separate operations by the server. Starting a request operation matchable to a previous operation and even using the same Request-Tag value is called request tag recycling.  The absence of a Request-Tag option is viewed as a value distinct from all values with a single Request-Tag option set; starting a request operation matchable to a previous operation where neither has a Request-Tag option therefore constitutes request tag recycling just as well (also called "recycling the absent option"). Clients that use Request-Tag for a particular purpose (like in req- tag-applications) MUST NOT recycle a request tag unless the first operation has concluded.  What constitutes a concluded operation depends on that purpose, and is defined there. </ins> When Block1 and Block2 are combined in an operation, the Request-Tag of the Block1 phase is set in the Block2 phase as well for otherwise

Discussion:
Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving. Rationale as in the review response mail: Reference made more precise, "from a single endpopoint" added. Split up into separate sentences for better clarity. That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose. Rephrased to pull in the purpose before the MUST and make that explicit. The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something. (We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update). Added to the initial (now split up) paragraph of that section. Explicitly included as an option now. (Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).
Looks good.
Change:
A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in <del> ld-consts-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. </del> <ins> pto-handshake) for a new path, but the delay SHOULD NOT be considered an RTT sample. </ins> Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of

Discussion:
Moves some RECOMMENDEDs up and removes others which are already elsewhere in the draft and reference those sections. This was intended to address , which I can still do in this PR if NAME would like, but I still think of Min CWND and Initial CWND as constants per-connection, even if they're not truly constants.
Change:
5. <del> *Note to Reviewers* This section includes some material on UDP and TCP that may be tutorial for some readers.  We can decide how to explain that, if the working group feels that this tutorial material is worth keeping. Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless the reader participated in the QUIC working group. </del> Because networking resources are shared between users, a good place to start our discussion is how contention between users, and mechanisms to resolve that contention in ways that are "fair" between

Discussion:
Remove this material from Sec 5: This section includes some material on UDP and TCP that may be tutorial for some readers. We can decide how to explain that, if the working group feels that this tutorial material is worth keeping. Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless the reader participated in the QUIC working group.
Change:
RFC5705 defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF).  This document replaces the PRF with HKDF, thus requiring a new construction.  The exporter interface <del> remains the same.  If context is provided, the value is computed as: </del> <ins> remains the same. The exporter value is computed as: </ins> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless <del> explicitly specified by the application.  When adding TLS 1.3 to TLS 1.2 stacks, the exporter_secret MUST be for the existing exporter interface. If no context is provided, the value is computed as above but with a zero-length context_value.  Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes. Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </del> <ins> explicitly specified by the application.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as providing an empty context.  This is a change from previous versions of TLS where an empty context produced a different output to an absent context.  As of this document's publication, no allocated exporter label is used both with and without a context.  Future specifications MUST NOT define a use of exporters that permit both an empty context and no context with the same label.  New uses of exporters SHOULD provide a context in all exporter computations, though the value could be empty. </ins> 8.

Discussion:
I found the wording a little hard to follow. This also by being very explicit about the presence of the change.
This changeset includes some "URL" cruft that isn't part of a reword.
In previous versions of TLS, passing no context was different to passing an empty context. TLS 1.3 doesn't distinguish between these. I don't know how important it is to highlight that minor difference, but it's probably worth mentioning.
So I should read more carefully: there is text about this, but it's not clear that this is a change from previous versions.
Change:
between the and the . While the is a distinct HTTP resource from the , they are both logically under the control of the Oblivious Gateway, since the can unilaterally dictate the responses returned from the to <del> the . This arrangement is shown in fig-overview.  See security for more information about and Oblivious Relay, and Oblivous Gateway resources in running this protocol. </del> <ins> the . This arrangement is shown in fig-overview. </ins> 2.1.

Discussion:
This talks about the odd case where target and gateway are separate. The primary insight here is that the target is just a regular HTTP resource and the requests from the gateway aren't special. Problems only occur if the gateway is privileged in some way. If abuse comes via the gateway, then the target would ordinary block the client, which tends to affect a bunch of bystanders in this model. So there is pressure to do something special for the gateway. In that case, the target is trusting the gateway in some way. Explain that. The heading here is the only case where we use the short names of the entities, but I can't stand short headings.
The changes are a big step forward in the right direction, but the flow seems a little weird as the text in the first part of the security section is about co-located gateway/target. Strongly suggest to move the added new text at the end of the whole section and add a forward reference in the text: (from the intro in the security section)
And, just to be clear, the PR text addresses my concern. My comment about the flow is just editorial.
I've taken the suggestion to move the text (with forward references) and made a few tweaks: Rebased. Moved and rewritten some text from the top of the security considerations that better fit the new section. Added a forward reference to this section. Moved and rewritten text added in to the applicability section. (Originally this was just to correct a misspelling, but I think this makes more sense in the new home.) NAME can you double-check my work. With this, I think we're ready to revise the draft and ask the IESG to finalize their ballot.
Change:
5. <del> TBD: None </del> <ins> This document registers the media type for Captive Portal API JSON text, "application/captive+json". application captive+json None None Encoding considerations are identical to those specified for the "application/json" media type. See This document specifies format of conforming messages and the interpretation thereof. This document This media type is intended to be used by servers presenting the Captive Portal API, and clients connecting to such captive networks. None See Authors' Addresses section. COMMON None CAPPORT IETF WG IETF </ins> 6.

Discussion:
Satisfied
application/json is fine in the general sense, but if you want to ever do things like versioning, then a media type is important. Crib from if you want a recent example.
Discussed in London, consensus to use a new media type.
I am ok with the added text.
Change:
VDAF-specific message for each report share. To begin this process, the helper first checks if it recognizes the <del> task ID, if not then it responds with HTTP status code 400 Bad Request and an error of type "unrecognizedTask".  Then the helper checks that the report IDs in "AggregateInitializeReq.report_shares" are all distinct.  If two ReportShare values have the same report ID, then the helper MUST abort with error "unrecognizedMessage".  If this check succeeds, the helper then attempts to recover each input share in "AggregateInitializeReq.report_shares" as follows: </del> <ins> task ID, if not then it MUST abort with error "unrecognizedTask". Then the helper checks that the report IDs in "AggregateInitializeReq.report_shares" are all distinct.  If two ReportShare values have the same report ID, then the helper MUST abort with error "unrecognizedMessage".  If this check succeeds, the helper then attempts to recover each input share in "AggregateInitializeReq.report_shares" as follows: </ins> Decrypt the input share for each report share as described in input-share-decryption.

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged
Change:
MUST NOT send records larger than the protocol-defined limit, unless explicitly allowed by a future TLS version or extension. <del> The size limit expressed in the "record_size_limit" extension doesn't account for expansion due to compression or record protection.  It is expected that a constrained device will disable compression and know - and account for - the maximum expansion possible due to record protection based on the cipher suites it offers or selects.  Note that up to 256 octets of padding and padding length can be added to block ciphers. </del> The record size limit only applies to records sent toward the endpoint that advertises the limit.  An endpoint MAY send records that are larger than the limit it advertises as its own limit.

Discussion:
The idea of this change is to try to constrain how much padding a sender can add. This is done by calculating the size of a record with maximum plaintext and minimum padding. No other record can exceed this size, though smaller packets can pad to reach this size. I was going to include a formula, then realized that the simple answer is best: pad to the record size limit, then pad to get to a multiple of the block size as normal. Most implementations will be OK because they don't bother with the first step.
Change:
contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): <del> A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST silently skip over that capsule. The length of the Capsule Value field following this field, encoded as a variable-length integer.  Note that this field can have a value of zero. The payload of this capsule.  Its semantics are determined by the value of the Capsule Type field. </del> Because new protocols or extensions may involve defining new capsule types, intermediaries that wish to allow for future extensibility SHOULD forward capsules unmodified.  One exception to this rule is

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
In order to be fully functional, the owner of the 'arpa.' zone must add a delegation of 'service.arpa.' in the '.arpa.' zone RFC3172. This delegation should be set up as was done for 'home.arpa', as a <del> result of the specification in RFC8375. </del> <ins> result of the specification in RFC8375.  This is currently the responsibility of the IAB </ins> 8.

Discussion:
Add a reference to the IAB statement on the registration of special use names in the ARPA domain.
Change:
5. <del> This specification defines the following new Internet media types </del> <ins> This specification defines the following new Internet media type </ins> MEDIATYPE. IANA has updated the "Media Types" registry at

Discussion:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via
Change:
If the HTTP request has a message body, such as an HTTP POST or PUT method, the payload of the JWS object is the JSON serialized body of the request, and the object is signed according to JWS and serialized <del> into compact form RFC7515.  The client instance presents the JWS as the body of the request along with a content type of "application/ jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing. </del> <ins> into compact form RFC7515.  The signer presents the JWS as the body of the request along with a content type of "application/jose".  The verifier MUST extract the payload of the JWS and treat it as the request body for further processing. </ins> If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use
Change:
Related information: None <del> 9.8. </del> <ins> 9.9. </ins> IANA has added the media type 'application/edhoc' to the Media Types registry.

Discussion:
Discussion today in COSE on how to do RPK by value in EDHOC. Suggestions to send a COSE_Key or a C509. Additional suggestion from Carsten to use CWT. Several issues in the old GitHub on CWTs, that were not transfered to the new GitHub: URL URL URL Discussion to transfer CWT in kid, in Auxilery data, and as COSE header parameter. Transfering CWT is related to issues , , ,
I made a pull request for this URL I think it is essential that EDHOC supports CWT. CWTs are much more flexible than X.509 / C.509. I think both are needed. The need for CWT has been discussed since 2016. I think it was decided clear quite early that transporting CWT is needed but was a discussion on how to transfer them. In Aux Data, in COSE header parameter, or in the kid bstr. For some reason nothing was ever specified. TLS WG is discussing to add support for CWT. URL I think certificates and CWT needs to be included, I am not sure that we need a different format for RPK. Likely CWT or C509 can be used for this purpose.
I think it should be discussed if CWT is good enough for the . My initial understanding is that it is but this needs to be analyzed and discussed. My current thoughts. CWT needs to be supported in EDHOC. Most things in CWT is optional, it is likely an optimized enough format for the oportunistic / TOFU use case of "RPK". CWT is also very flexible. When CWT exist it would be strange to standardize a new format for transfereing a COSEKey unless it is really really needed to save bytes. CWT + Deterministic CBOR could maybe replace the discussion on how to integrity protect COSEKeys. We should at least remove the new subjectname from the COSEKey part in the EDHOC document. CWT and C509 can be used when subject name is needed. Does "Raw" COSE_Keys that are not CWT even need to be supported? Or would CWT / C509 / X.509 be enough
This change has now been done in the master branch, see a1b25ba and commits in its vicinity. Can we close the issue?
This has now been addressed.
Change:
IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are <del> taken from the table.  The "DTLS-OK" column is marked as "Yes". IANA [SHALL add/has added] a "Recommended" column to the cipher suite registry.  All cipher suites listed in cipher-suites are marked as "Yes".  All other cipher suites are marked as "No". IANA [SHALL add/has added] add a note to this column reading: Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. </del> <ins> taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes draft-sandj-tls-iana-registry-updates-00 has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC2434.

Discussion:
We are inconsistent about "AEAD cipher" and "AEAD algorithm". RFC 5116 uses "AEAD algorithm" and "AEAD cipher" is confusing with "cipher suite", so standardize on algorithm. IANA considerations were never updated to actually add the cipher suites. Fix that. Match the cipher suite name column with the IANA name so we can reuse the table. Finally, since we are defining new cipher suites, we should take care to cite where our AEADs come from. Do so.
Change:
Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned <del> above; note that receipt of an ICE candidate is not required. </del> <ins> above.  Note that the agent will start the timer even if it has not sent or received any ICE candidates. </ins> The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all

Discussion:
I committed both changes.
WHERE: Update to RFC 8445 WHAT: Modify... "; note that receipt of an ICE candidate is not required." URL that it also indicates that no candidate needs to be SENT before the timer is started. WHY: The text in unclear on whether a candidate needs to be sent or not before the timer is started. The text only says that a candidate does not need to be received.
ok
Implemented in
LG with two minor wording changes