jiebi/CodeConvo huggingface dataset:
Change:
processing according to I-D.ietf-detnet-mpls. It is the responsibility of the DetNet controller plane to properly <del> provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and individual flows. </del> <ins> provision both flow identification information and the flow-specific resources needed to provide the traffic treatment to meet each flow's service requirements.  This applies for aggregated and individual flows. </ins> 7.

Discussion:
Note added to 5.1, that L4 multipath is out-of-scope. Please, check note and its placement that it is appropriate. URL URL Internet-Draft draft-ietf-detnet-ip-oam-URL is now available. It is a work item of the Deterministic Networking (DETNET) WG of the IETF. Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Authors: Greg Mirsky Mach(Guoyi) Chen David Black Name: draft-ietf-detnet-ip-oam-URL Pages: 9 Dates: 2024-02-05 Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTML version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
Hi Bernard, thank you for your thoughtful comments and helpful suggestions. The authors discussed them and updated the draft to address your concerns. I uploaded the new version: A new version of Internet-Draft draft-ietf-detnet-ip-oam-URL has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-detnet-ip-oam Revision: 11 Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Date: 2024-02-05 Group: detnet Pages: 9 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. Please let us know whether these updates adequately address your comments. Our sincere thanks for your help in improving this document. Regards, Greg (on behalf of the authors)
Change:
packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset <del> Tokens that are associated with connection IDs that the endpoint recently used to send packets from the IP address and port on which the datagram is received.  This includes Stateless Reset Tokens from </del> <ins> Tokens corresponding to active connection IDs that the endpoint has used for sending packets to the IP address and port on which the datagram is received.  This includes Stateless Reset Tokens from </ins> NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have

Discussion:
The editors assumed this was true, but I think it's worth stating this as a MUST to ensure clarity.
I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?
Also, when ACKs packets don't fit in packets, this would also hold for ACK'ing ack-eliciting packets. So you could end up having to not ACK'ing some packets and induce loss. Requiring an ACK for all packets would be problematic. I'm not sure we want that. The result could be very hard to implement while the practical benefit would be small: sending multiple ACK packets with different content due to overflow.
I just synced to master and now this seems to be an editorial change, at least to me. That being said, PTAL at the text and tell me if there are any other changes I should make.
It appears that the spec doesn't actually require sending ACKs for every ACK-eliciting packet. This could lead to a perverse implementation just not ACKing things with obvious problems.
Discussed in Cupertino. Add normative language to prescribe what should be ACKed. Reclassifying as Editorial (adds normative language, but we have consensus on that).
Generally looks good, but I don't think we can have an absolute requirement that every ack-eliciting packet is acknowledged.
Change:
This section registers the "application/cose" and "application/ cose+cbor" media types in the "Media Types" registry.  [CREF11] These media types are used to indicate that the content is a COSE_MSG. <ins> [CREF12] </ins> Type name: application

Discussion:
Create IANA considerations for: 1) key and keyset CBOR tags 2) COAP Content Format registrations
Change:
denoted skI and pkI, respectively, used to produce tokens.  Each key pair SHALL be generated as as specified in FIPS 186-4 DSS. <del> The key identifier for a keypair (skI, pkI), denoted "key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash </del> <ins> The key identifier for a keypair (skI, pkI), denoted "token_key_id", is computed as SHA256(encoded_key), where encoded_key is a DER- encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash </ins> algorithm and salt size.  The salt size MUST match the output size of the hash function associated with the public key and token type. <ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation. </ins> 7. This document outlines how to instantiate the Issuance protocol based <del> on the VOPRF defined in OPRF and blind RSA protocol defnied in BLINDRSA.  All security considerations described in the VOPRF document also apply in the Privacy Pass use-case.  Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the Architecture document I- D.ietf-privacypass-architecture. </del> <ins> on the VOPRF defined in OPRF and blind RSA protocol defined in BLINDRSA.  All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the Architecture document I-D.ietf-privacypass-architecture. Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This is done to minimize the chance that an Issuer can use distinct keys for targeting specific users.  Since the key ID is truncated to a single byte, an Issuer can partition the set of Clients into at most 256 different anonymity sets.  On top of this key ID space, Clients SHOULD apply some form of key consistency mechanism to help ensure they are not being given unique keys; see CONSISTENCY for more details. </ins> 8.

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
endpoint to retrieve the server's discovery information.  The AS MUST respond with a JSON document containing the following information: <del> REQUIRED.  The full URL of the AS's grant request endpoint.  This MUST match the URL the client instance used to make the discovery request. </del> <ins> REQUIRED.  The location of the AS's grant request endpoint.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST match the URL the client instance used to make the discovery request. </ins> OPTIONAL.  A list of the AS's capabilities.  The values of this result MAY be used by the client instance in the request-

Discussion:
Suggested changes for URL They could be also simplified to something like
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 0569eb3db265511e06d7fb19b2320081d4626430 https://deploy-preview-183--gnap-core-protocol-editors-URL
Sections "9 Discovery" states that It makes sense to specify that this URL should be using HTTPS. I also don't think you want to allow using the fragment component in it, as well as query parameters. The query parameters could be arguable though...
This definition should be beyond just the discovery portion -- this endpoint is fundamental to the protocol and it does need to be protected. We can at least mention that it starts with HTTPS here. Prohibiting fragments makes sense, but prohibiting query parameters or any other URL portion does not make sense, though, as that could be important to an AS's deployment. However, the client instance always takes this string as-is and doesn't add or modify anything, and it always makes a POST to it.
URL
I've reused the definition of . That is a very precise one IMO.
Change:
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a previously issued connection ID with a different Stateless Reset <del> Token or a different sequence number, or if a sequence number is used for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. </del> <ins> Token field value or a different Sequence Number field value, or if a sequence number is used for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. </ins> The Retire Prior To field applies to connection IDs established during connection setup and the preferred_address transport

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
(decimal) inclusive are assigned via Specification Required RFC2434.  Values from 224-255 (decimal) inclusive are reserved for Private Use RFC2434. <del> 12.  References 12.1.  URIs [1] https://github.com/tlswg/tls13-spec/issues/32 </del>

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:
Resumed connections over the same network MAY use the previous connection's final smoothed RTT value as the resumed connection's initial RTT.  When no previous RTT is available, the initial RTT <del> SHOULD be set to 333ms, resulting in a 1 second initial timeout, as recommended in RFC6298. </del> <ins> SHOULD be set to 333ms.  This results in handshakes starting with a PTO of 1 second, as recommended for TCP's initial retransmission timeout; see Section 2 of RFC6298. </ins> A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in

Discussion:
Address validation can use 3*PTO, just taking the maximum of the old and new path PTO. The idea of initial timeout is easily replaced in recovery by instead describing the effect on the PTO. The net effect is the same, except that new paths often have to include the maximum ACK delay, which this doesn't incorporate.
A quick look in the reference did not show what units of time you are using in the protocol - maybe I missed it?
is set to 333ms. Not sure why a max between two values needs to define the unit in the first place though.
is not defined in -transport, and Stewart was (probably) only reviewing the document in isolation.
NAME a max needs to ensure both values use the same units. But provided that they do, I agree.
Maybe it's easier to say that these are all physical quantities, or numbers with units. In the specification, we use seconds, milliseconds, microseconds. That's fine, because we know how to align the units when we make calculations (e.g., max).
PR proposes removing the text in question. Of course, it doesn't matter what time units are in use in this case. I'm fairly confident that where units matter (i.e., we base the value on a constant), the units are explicit. Here, the units are part of the definition of the variables.
As Martin points out, the offending text was removed. Not seeing anything to be done here , so I'm closing the issue.
says "initial timeout (that is, )". But I don't think that we have this initial timeout concept in recovery any more; we . Should this just be now? The result is that the is meaningless as the PTO is when initialized. Or is this the PTO on the pre-existing path?
I think this is the case. Notice "current." Therefore I belive that the formula should be .
Changing 2kInitialRtt to 3kInitialRtt and 6kInitialRtt to 9kInitialRtt seems like the simplest fix since we don't define an initial_PTO variable anywhere in the documents.
I assume that the choice between and is purely editorial. Either works for me.
I prefer with some changes that I've noted on the PR.
I think this is correct. LGTM, but waiting for NAME to take a look.
Change:
cipher_suite contains the client's chosen HpkeCipherSuite; <del> config_digest contains the digest of the corresponding ECHConfig </del> <ins> config_id contains the identifier of the corresponding ECHConfig </ins> structure; enc contains the encapsulated key as output by SetupBaseS; and

Discussion:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)
Change:
I-D.ietf-rats-tpm-based-network-device-attest as well as the interaction model and information elements defined in I-D.ietf-rats- reference-interaction-models.  The currently supported hardware <del> security modules are the Trusted Platform Module (TPM) TPM1.2 and TPM2.0 specified by the Trusted Computing Group (TCG).  One or more TPMs embedded in the components of a Composite Device are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting in order to retrieve attestation Evidence from a composite device (quote primitive operation). Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (extend primitive operation). </del> <ins> security modules (HSMs) are the Trusted Platform Modules (TPMs) TPM1.2 and TPM2.0 as specified by the Trusted Computing Group (TCG). One or more TPMs embedded in the components of a Composite Device are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence from a composite device (_TPM Quote_ primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (_TPM PCR Extend_ primitive operation). </ins> Specific terms imported from I-D.ietf-rats-architecture and used in this document include: Attester, Composite Device, Evidence. Specific terms imported from TPM2.0-Key and used in this document <del> include: Endorsement Key (EK), Initial Attestation key (IAK), Local </del> <ins> include: Endorsement Key (EK), Initial Attestation Key (IAK), Local </ins> Attestation Key (LAK). 1.1.

Discussion:
Basically, this fixes typos, grammar, and consistency. And, all above, the TPM 2.0 quote information, which was set to TPMSQUOTEINFO. Actually it is TPM2B_ATTEST. Further Issues to be created.
TPM 2.0 quote information (attestation data) is of type TPM2BATTEST, not TPMSQUOTEINFO. TPMSQUOTEINFO is a sub element of the TPM2BATTEST. In a TPM2Quote operation, the TPM signs a hash of the TPM2BATTEST structure. The signature is of type TPMT_SIGNATURE (just FYI).
Change:
The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined <del> in this document.  Any later, incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name. </del> <ins> in this document. </ins> The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. <del> Encrypt the result of expand_left(left_0) to obtain a ciphertext. </del> <ins> Encrypt the result of expand_left(left_0, index)) to obtain a ciphertext, where 'index' is one octet: the two most significant bits of which are 0b00, and the six least significant bits are the length of the resulting connection ID in bytes, cid_len. </ins> XOR the least significant bits of the ciphertext with right_0 to form right_1. Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ <del> truncate_right( AES_ECB(key, expand_left(left_0, 0x01)), </del> <ins> truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1)), </ins> len(right_0)) " Repeat steps 3 and 4, but use them to compute left_1 by expanding <del> and encrypting right_1 with the most significant octet as 0x02 and XOR the results with left_0. </del> <ins> and encrypting right_1 with the most significant octet as the concatenation of 0b01 and cid_len, and XOR the results with left_0. </ins> "left_1 = left_0 ^ truncate_left( AES_ECB(key, <del> expand_right(right_1, 0x02)), len(left_0)) " </del> <ins> expand_right(right_1, cid_len, 2)), len(left_0)) " </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding <del> and encrypting left_1 with the least significant octet as 0x03 and XOR the results with right_1. </del> <ins> and encrypting left_1 with the least significant octet as the concatenation of 0b10 and cid_len, and XOR the results with right_1. </ins> "right_2 = right_1 ^ truncate_right( AES_ECB(key, <del> expand_left(left_1, 0x03)), len(right_1)) " </del> <ins> expand_left(left_1, cid_len, 3), len(right_1)) " </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding <del> and encrypting right_2 with the most significant octet as 0x04 and XOR the results with left_1. </del> <ins> and encrypting right_2 with the most significant octet as the concatenation of 0b11 ands cid_len, and XOR the results with left_1. </ins> "left_2 = left_1 ^ truncate_left( AES_ECB(key, <del> expand_right(right_2, 0x04)), len(left_1)) " </del> <ins> expand_right(right_2, cid_len, 4), len(left_1)) " </ins> The server concatenates left_2 with right_2 to form the ciphertext CID, which it appends to the first octet.

Discussion:
in accordance with the 2nd crypto review
In the second crypto review () there was a note that plaintexts of different lengths might end up with similar results, if the extra bits were zeros. The suggestion to fix this was to update the path index to also include the length.
Looks good, except for the missing parenthesis.