jiebi/CodeConvo huggingface dataset:
Change:
0-RTT (packet-0rtt) <del> 1-RTT (short-header) </del> <ins> 1-RTT (packet-1rtt) </ins> Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake packets.

Discussion:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.
Change:
application layer and therefore no additional data is expected from both sides. <del> An immidate close will emit an CONNECTION_CLOSE frame.  This frames </del> <ins> An immediate close will emit an CONNECTION_CLOSE frame.  This frames </ins> 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- <del> specific error codes (see, for example, 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 </del> <ins> specific error codes (see, for example, QUIC-HTTP, Section 8.1). The CONNECTION_CLOSE frame provides an optional reason field, that </ins> can be used to append human-readable information to an error code. <del> 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. </del> <ins> Note that QUIC RESET_STREAM and STOP_SENDING frames also include an error code, but no reason string.  Application error codes are expected to be defined from a single space that applies to all three frame types. </ins> Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated by a transport parameter in the handshake, the idle timeout is announced for each endpoint during connection establishment and the <del> effective value for this connection is the minimum of the two advertised values.  An application therefore should be able to configure its own maximum value as well as have access to the </del> <ins> effective value for this connection is the minimum of the two values advertised by client and server.  An application therefore should be able to configure its own maximum value as well as have access to the </ins> computed minimum value for this connection.  An application may adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory <del> more quickly.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alive messages, or a QUIC implementation may provide an option to defer the time-out to avoid unnecessary load, as specified in Section 10.1.2 of QUIC.  See resumption-v-keepalive for further guidance on keep- alives. </del> <ins> more quickly. If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alive messages, or a QUIC implementation may provide an option to defer the time-out to avoid unnecessary load, as specified in Section 10.1.2 of QUIC.  See resumption-v-keepalive for further guidance on keep-alives. </ins> 9.

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.
Change:
possible for HTTP Upgrade or Extended CONNECT. The Capsule-Protocol header field MUST NOT be used on HTTP responses <del> with a status code that is both different from 101 and outside the 2xx range. </del> <ins> with a status code that is both different from 101 (Switching Protocols) and outside the 2xx (Successful) range. </ins> When using the Capsule Protocol, HTTP endpoints SHOULD send the Capsule-Protocol header field to simplify intermediary processing.

Discussion:
In the following text, should the names of the status codes appear as they do in the rest of the document? Original: ...a status code that is both different from 101 and outside the 2xx range. Perhaps: ...a status code that is both different from 101 (Switching Protocols) and outside the 2xx (Successful) range.
solid improvement, let's do it
That sounds good to me
Change:
When both aggregators' shares are successfully obtained, the leader responds to subsequent HTTP GET requests to the collect job's URI <del> with HTTP status 200 OK and a body consisting of a "CollectResult": </del> <ins> with HTTP status 200 OK and a body consisting of a "CollectResp": </ins> "shares" is a vector of "EncryptedAggregateShare"s, as described in aggregate-share-request, except that for the leader's share,

Discussion:
CollectResp is paired with CollectReq; naming things this way matches other {Req, Resp} message pairs.
Change:
4. ACME allows a client to request certificate management actions using <del> a set of JavaScript Object Notation (JSON) messages carried over HTTPS RFC8259 RFC2818.  Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a </del> <ins> a set of JavaScript Object Notation (JSON) messages RFC8259 carried over HTTPS RFC2818.  Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a </ins> certificate, and proves control of the domain(s) in that certificate in order for the CA to issue the requested certificate.

Discussion:
Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.
Change:
example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the response).  Query parameters in PUT and POST requests do not have <del> such established semantics and are not commonly used. </del> <ins> such established semantics and are not commonly used.  Whether the order of the query parameters matters in URIs is unspecified and they can be re-ordered e.g., by proxies.  Therefore applications should not rely on their order; see Section 3.3 of RFC6943 for more details. </ins> 3.5.

Discussion:
Removed "path is hierarchical query not" comment. Added note about query component order being unspecified.
This addresses issue
URL
Fixed in PR Hi, In reading draft-keranen-t2trg-rest-iot-01 I note the following: It is my understanding that this statement is subject to debate. Certainly some RESTful APIs assign hierarchical semantics to the path. For example, /foo may refer to a "collection-style" resource and /foo/bar may refer to a resource within that collection. However, is this a necessary requirement? From my perspective, this could potentially limit extensibility as future revisions of a RESTful API may, for instance, wish to insert a resource "between" /foo and /foo/bar. If the resources themselves are truly self-describing, containing links to "subordinate" resources, then the path portion of the URI can become an opaque identifier and backward compatibility in this hypothetical RESTful API could be maintained. Likewise, I have seen RESTful APIs where the order of the elements in the query portion of the URI matters (particularly if a given element occurs multiple times). I would suggest staying silent on the semantics of these parts of the URI or noting that they MAY be hierarchical / non-hierarchical. Thanks, Robby
Change:
location controlled by the attacker.  Implementations MUST either choose to terminate the call or display a warning at that point. <ins> Also note that the security architecture depends on the keying material not being available to move between origins.  But, it is assumed that the identity assertion can be passed to anyone that the page cares to. </ins> 5.2. Implementations MUST obtain explicit user consent prior to providing

Discussion:
This is an (lame) attempt to I'm, not sure the text is in the right place even. NAME NAME NAME NAME PTAL As far as I know this is the last technical security issue.
As described in the (mailing list discussion)[URL] As the RTCCertificates are allowed to be stored or transferred across domains via postMessage it could allow a potential attacker to reuse a past identity assertion when it is no longer valid. A possible solution would to generate an unique dtls external session Id per peerconnection as described in URL and provide that information to the generate and validate assertion js methods.
I think where this conversation ended up, based on Harald's email: URL Means that the security arch draft needs to say that the security architecture depends on the keying material not being available to move between origins, but that we understand and assume that the identity token can be passed to anyone that the page cares to. And, Martin also added this PR to the WebRTC spec: Also URL To make sure we're all on the same page: The identity token is a JSON blob - ie a string. There's absolutely no way to prevent the page from passing it to anyone it wants to pass it to - and there shouldn't be. In contrast, the RTCCertificate is an object with an interface that has a specific guarantee: "No mechanism is provided for applications to access the [[KeyingMaterial]] internal slot." and therefore this further statement can be made to implementors: "In implementations where an RTCCertificate might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the [[KeyingMaterial]] internal slot, allowing the private key to be stored and used." I think it doesn't make sense to move such an object between origins. We might want to state that explictly. (But that's a W3C issue, so ought to be addressed to a different list.)
Change:
In pseudocode, this procedure is as follows: <del> 4.2. </del> <ins> 4.4. </ins> Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows:

Discussion:
This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?
Change:
clients. Applications SHOULD constrain tokens to a single origin unless the <del> use case can accommodate such replay attacks. </del> <ins> use case can accommodate such replay attacks.  Replays are also possible if the client redeems a token sent as part of 0-RTT data. If successful token redemption produces side effects, origins SHOULD implement an anti-replay mechanism to mitigate the harm of such replays.  See RFC8446, Section 8 and RFC9001, Section 9.2 for details about anti-replay mechanisms, as well as RFC8470, Section 3 for discussion about safety considerations for 0-RTT HTTP data. </ins> All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness.

Discussion:
The security considerations of the auth scheme should mention 0-RTT specifically in its discussion of token replay.
Change:
outer IP header.  The new header is placed after this new outer IP header. <del> A corollary is that an RH3 or RPL Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 Header, which is addressed TO the intermediate router.  When it does so, the </del> <ins> A corollary is that an intermediate router can remove an RH3 or RPL Option only if it is placed in an encapsulating IPv6 Header that is addressed TO this intermediate router.  When doing the above, the </ins> whole encapsulating header must be removed.  (A replacement may be added).  This sometimes can result in outer IP headers being addressed to the next hop router using link-local address.

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
8. <del> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC </del> <ins> In the example TLS 1.3 handshake shown in fig-handshake, a client and a server successfully negotiate support for CID as well as the RRC </ins> extension. Once a connection has been established the client and the server <del> exchange application payloads protected by DTLS with an unilaterally used CIDs.  In our case, the client is requested to use CID 100 for </del> <ins> exchange application payloads protected by DTLS with a unilaterally used CID.  In our case, the client is requested to use CID 100 for </ins> records sent to the server. At some point in the communication interaction the IP address used by the client changes and, thanks to the CID usage, the security context to interpret the record is successfully located by the server. However, the server wants to test the reachability of the client at <del> his new IP address. </del> <ins> its new IP address. fig-rrc-example shows the server initiating a "basic" RRC exchange (see regular) that establishes reachability of the client at the new IP address. </ins> 9.

Discussion:
/cc NAME Signed-off-by: Thomas Fossati
This is important and so the example should show it.
The draft splits the probes in and . The example demonstrates the so I think, we should add that to the figure description "Basic Return Routability Example".
Change:
<del> Mode of Operation extension and Capabilities draft-ietf-roll-mopex-cap-latest </del> <ins> RPL Capabilities draft-ietf-roll-capabilities-latest </ins> Abstract <del> RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network.  The MOP field in RFC6550 is of 3 bits and is fast depleting.  This document extends the MOP field specification and adds a notion of capabilities using which the nodes can further advertise their support for, possibly optional, capabilities. </del> <ins> This draft enables the discovery, advertisement and query of capabilities for RPL nodes. </ins> 1.

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
As described in client-compromise, MLS provides strong authentication within a group, such that a group member cannot send a message that appears to be from another group member.  Additionally, some services <del> require that a recipient be able to prove to the messaging service </del> <ins> require that a recipient be able to prove to the service provider </ins> that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases.  In some deployments, these services are provided by mechanisms which allow the receiver to prove

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
edge computing devices (or deferred to off-peak hours or using physical shipping); and downlink for control and software updates. <del> 7.2. </del> <ins> 6.2. </ins> <del> 7.2.1. </del> <ins> 6.2.1. </ins> In traditional construction domain, there are many heavy equipment and machineries and dangerous elements.  Even though human pay

Discussion:
Main change: Merged 2 sections (IoT Integrated with Edge Computing and architecture section) into a new "model" section. Updated the architecture diagram into a model diagram including the logical functions proposed by Dirk. Heavily reworded/simplified text from the previous 2 sections - I tried to keep relevant info, but removed what was redundant with the existing challenges section. The architectures (gateway vs. distributed) are shortly listed above the figure, but the rest aims to be general. Some renaming for your consideration (feel free to ignore/change): new draft title: IoT Edge Computing Challenges, Model and State-of-Art Review challenges section ("new IoT challenges" could seem a bit general): Challenges for IoT and Impacts of Edge Computing Minor: edits in abstract
Yong-Geun, Jungha, and Dirk agreed via e-mail. Since the new version has been sent to the Datatracker, I will merge.
Change:
8.1. In the absence of an application profile standard specifying <del> otherwise, a TLS-compliant application MUST implement the cipher suite TODO:Needs to be selected [1].  (See cipher-suites for the definition.) </del> <ins> otherwise, a TLS-compliant application MUST implement the following cipher suites: These cipher suites MUST support both digital signatures and key exchange with secp256r1 (NIST P-256) and SHOULD support key agrement with X25519 I-D.irtf-cfrg-curves. A TLS-compliant application SHOULD implement the following cipher suites: </ins> 8.2.

Discussion:
NAME please confirm this matches consensus
Now that we are removing static RSA cipher suites, we need a new MTI cipher suite.
From Sean's mail o Symmetric: MUST AES-GCM 128 [SHOULD ChaCha20-Poly1305] o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 [SHOULD 25519] o Signature: MUST ECDSA P-256 MUST RSA
Dear Mr. NAME currently I'm very interested in studying non-repudiation, then I found S-HTTP (RFC 2660) that offer non-repudiation security service. I also found that AS2 (RFC 4130) also offers this kind of service, but then I wonder why non-repudiation service is not becoming ubiquotus? Why AEAD replace HMAC, does hash function is too heavy, or hash is more appropriate for digital signature world? Thanks
Change:
fig-auth-cid-retry shows a similar handshake that includes a Retry packet. <del> For the handshakes in fig-auth-cid and fig-auth-cid-retry the client sets the value of the initial_source_connection_id transport parameter to "C1".  In fig-auth-cid-retry, the server sets original_destination_connection_id to "S1", </del> <ins> In both cases (fig-auth-cid and fig-auth-cid-retry), the client sets the value of the initial_source_connection_id transport parameter to "C1". When the handshake does not include a Retry (fig-auth-cid), the server sets original_destination_connection_id to "S1" and initial_source_connection_id to "S3".  In this case, the server does not include a retry_source_connection_id transport parameter. When the handshake includes a Retry (fig-auth-cid-retry), the server sets original_destination_connection_id to "S1", </ins> retry_source_connection_id to "S2", and initial_source_connection_id <del> to "S3".  In fig-auth-cid, the server sets original_destination_connection_id to "S1", initial_source_connection_id to "S3", and does not include retry_source_connection_id.  Each endpoint validates the transport parameters set by their peer, including the client confirming that retry_source_connection_id is absent if no Retry packet was processed. </del> <ins> to "S3". Each endpoint validates transport parameters set by the peer.  The client confirms that the retry_source_connection_id transport parameter is absent if it did not process a Retry packet. </ins> 7.4.

Discussion:
An attempt to make this slightly easier to read, based on feedback that this was hard to read and follow.
Looks good, but I think the paragraph on lines 1574 to 1582 might be best split too, into sub-paragraphs for each TP and how it's used.
Change:
an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern. <ins> Only the header field name stored in the static or dynamic table is used.  Any header field value MUST be ignored. </ins> The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST

Discussion:
A couple of clarifications that can be useful to people who are looking at *PACK for the first time like myself. Not sure about the normative language though. I can reword it if necessary.
Let's see how handles it: We could simply add similar verbiage to Sections and 4.5.5. of the QPACK draft instead.
NAME I can add something like that, but TBH I don't think that the HPACK wording would have helped me, so I'd rather keep my clarification (that says "ignore value") as well.
This wording seems fine.