jiebi/CodeConvo huggingface dataset:
Change:
4. <del> When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP address and port number with the source specified in the UDP datagram before cryptographically validating the enclosed record(s) but instead perform a return routability check. </del> <ins> This document defines the "return_routability_check" content type (fig-rrc-msg) to carry Return Routability Check protocol messages. </ins> <del> The cookie is a 8-byte field containing arbitrary data. </del> <ins> The protocol consists of three message types: "path_challenge", "path_response" and "path_drop" that are used for path validation and selection as described in path-validation. Each message carries a Cookie, a 8-byte field containing arbitrary data. </ins> The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <ins> Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able to parse and ignore unknown values. </ins> 5. <ins> RRC offers an in-protocol mechanism to perform peer address validation, thus complementing the "peer address update" procedure described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as described in path-validation. 6. </ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path

Discussion:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.
Change:
specifications which may use this mechanism to configure the usage of STUN/TURN servers. <del> There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. </del> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. <ins> There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent.  However, this method is not NOT RECOMMENDED and if supported by the underlying WHIP Client's webrtc implementation, the WHIP Client SHOULD wait for the information to be returned by the WHIP Endpoint on the response of the HTTP POST request instead. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to

Discussion:
NAME could you take a look please?
The current text ignores the issue that (in the absence of OPTIONS) the offer must be sent before it is set as the local description, in order to avoid starting the ICE agent prematurely. I think we should consult an ICE specialist in order to understand what consequences that will have on connectivity.
There is already a note already covering that case. It is up to the WHIP client implementation to know which is its ICE implementation support regarding this case and choose to call setLocalDescription or not before updateConfiguration. The only case were a WHIP client is not tightly coupled with a ICE implementation is on browsers, and we already have checked that it works on all webrtc browsers.
Change:
4.1.1. This is an example of how an application might listen for incoming <del> Connections using the Transport Services Interface, receive a </del> <ins> Connections using the Transport Services Interface, and receive a </ins> request, and send a response. 4.1.2. <del> This is an example of how an application might connect to a remote application using the Transport Services Interface, send a request, and receive a response. </del> <ins> This is an example of how an application might open two Connections to a remote application using the Transport Services Interface, and send a request as well as receive a response on each of them. </ins> 4.1.3.

Discussion:
I found the relationship between streams and connections to be extremely murky throughout the draft, and left it not really sure how I would control a streamed transport. Section 6.4 hints suggests that opening additional streams is an alternative implementation of Clone() for transports that can do so. Does this imply that if the peer stream limit does not allow new streams, the transport should open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are there two levels of listener: a stream listener and a connection listener? How would opening "stream listeners" relate to the maximum number of streams the peer could open (i.e. do I have to call listen() 8 times to allow the client to open 8 streams)? Or are there no stream listeners and these "connections" just sort of appear? Skimming the -impl draft, I can see there's some text here but it is not fitting together for me. There are at least three streamed transports and it would be helpful to explain how the API conceptualizes this, perhaps in a new section.
To clarify, Listen() is called once and keeps receiving streams within the NewConnectionLimit. The main thing to clarify is how the NewConnectionLimit applies to streams of a multiplexed transport. We could look at having a limit of connections per endpoint in a group from a listener.
Add a property to section 7.1.
Also make sure to have an early section being very explicit about the overall interaction model.
In section 4.1, we could add an example for explicit group management via clone, etc.
Sigh, I will never self-assign an issue again before its discussion :-) but it's ok... I'll do it
Change:
hash function is a CBOR Sequence.  Note that H(message_1) can be computed and cached already in the processing of message_1. <del> Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", ( ID_CRED_R, CRED_R, ? EAD_2 ), mac_length ).  If the Responder authenticates with a static Diffie-Hellman key (method equals 1 or 3), then mac_length is the EDHOC MAC length given by the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then mac_length is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </del> <ins> Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, CRED_R, ? EAD_2 >>, mac_length_2 ).  If the Responder authenticates with a static Diffie-Hellman key (method equals 1 or 3), then mac_length_2 is the EDHOC MAC length given by the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then mac_length_2 is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </ins> ID_CRED_R - identifier to facilitate retrieval of CRED_R, see

Discussion:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to
Change:
This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of <del> the Capacity Profile protocol and path selection property (see transport-params). </del> <ins> the Capacity Profile protocol and path selection property (see prop- cap-profile). </ins> The following values are valid for Instantaneous Capacity Profile:

Discussion:
Send parameters were subsections, transport selection properties were not. This fixes that by promiting transport selection properties to subsections, and reorganizing the sections slightly to make that fit. There are no changes to technical content in this PR.
Makes sense - had that one also on my list of ugliness to be fixed.
Change:
the MPTCP connection would continue to provide a regular TCP service. Since key generation is implementation-specific, there is no <del> requirement that they be simply random numbers.  An implemention is </del> <ins> requirement that they be simply random numbers.  An implementation is </ins> free to exchange cryptographic material out-of-band and generate these keys from this, in order to provide additional mechanisms by which to verify the identity of the communicating entities.  For

Discussion:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.
Change:
against all previous values, but a duplicate value MAY be treated as a connection error of type PROTOCOL_VIOLATION. <del> Note that Stateless Reset packets do not have any cryptographic protection. </del> <ins> Note that Stateless Resets do not have any cryptographic protection. </ins> 10.3.3.

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
identical, these are two different resources, in two distinct namespaces. <ins> Some schemes are for URIs with main purpose as identifiers and hence are not dereferencable, e.g., the "urn" scheme can be used to construct unique names in registered namespaces.  In particular the "urn:dev" I-D.ietf-core-dev-urn details multiple ways for generating and representing endpoint identifiers of IoT devices. </ins> The query parameters can be used to parametrize the resource.  For 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

Discussion:
Tweak a bit the message of this: non-resource identifiers are not really part of the REST style, but a system usually needs them and the IETF has good means with URIs, which include URNs, and can be used for such non-resource identifiers (e.g., for physical asset, device, etc.).
We added the terms to the terminology, but should explain a bit more at the end of the URI sections.
Solved in
Change:
suffix that can be interpreted by any compatible implementations and ignored otherwise. <del> 4. </del> <ins> 3. </ins> Multi-character namespaces are assigned by IANA using the "IETF Review" policy defined by RFC8126; the IETF review process needs to be based on the requirements laid out in multi-char. <del> 5. </del> <ins> 4. </ins> TBD

Discussion:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.
Change:
table, without sending any packets over the network. Finally, the socket can be queried using getsockname() or the <del> equivalent to determine the appropriate host candidate. </del> <ins> equivalent to determine the appropriate local address. </ins> 7.

Discussion:
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
Change:
where "sk" is the HPKE secret key, "task_id" is "AggregateReq.task_id" and "server_role" is the role of the server <del> that send the aggregate share ("0x01" for the leader and "0x00" for </del> <ins> that sent the aggregate share ("0x02" for the leader and "0x03" for </ins> the helper). "batch_interval" is the "Interval" from the "CollectReq".  The collector then unshards the aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result"

Discussion:
When constructing HPKE contexts, we now include both sender and recipient roles, and the application label also includes the PPM version. I used here because we recently submitted draft-01 of and so the next submitted draft, which would include this change, will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non-controversial we can get a head-start on bringing those changes into main.
Fixed, thank you! I also rewrote the relevant paragraph to acknowledge that there's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself. Further, I recall NAME pointing out to me that should this draft get adopted by the WG, we'll reset to something like , so is the more appropriate application label.
There's one more instance of that needs to be changed to . Otherwise, LGTM.
Change:
Remove support for non-AEAD ciphers. <ins> 1.3. This document defines several changes that optionally affect implementations of TLS 1.2: A version downgrade protection mechanism is described in server- hello. RSASSA-PSS signature schemes are defined in signature-algorithms. An implementation of TLS 1.3 that also supports TLS 1.2 might need to include changes to support these changes even when TLS 1.3 is not in use.  See the referenced sections for more details. </ins> 2. The cryptographic parameters of the session state are produced by the

Discussion:
The document was pretty crisp about the version downgrade protections, but was less good about the changes to signature schemes. I have made a few changes to the description of signature_algorithms that should improve that. In particular, I have made it clear that the RSASSA-PSS codepoints are also defined for TLS 1.2 and that they can be used there. That means that TLS implementations need to be prepared to accept PSS signatures. This also adds a section that points to the pieces that 1.2 implementations need to consider.
(Well, I think, strictly speaking, we need only lock down HashAlgorithm.) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges. I'm not sure how to write that kind of IANA consideration or I'd put together a PR. The end result should probably be something like s/Unassigned/Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards, all new signature algorithms that apply to TLS 1.2 must go through a backported SignatureScheme. (If we're not happy with that strong of a restriction, we could perhaps only burn HashAlgorithms 0x80 and up. Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range. Though 's PSS text already implies we'll be backporting SignatureSchemes, so the division probably isn't necessary? I dunno. I don't really care either way.)
Let's just lock down HAshAlgorithm. Can you submit a PR?
Change:
request through the use of a URI Template RFC6570.  Configuration and discovery of the URI Template is done out of band from this protocol. <del> The URI template defined in this document is processed without any variables for requests using POST, and with the single variable "dns" for requests using GET.  The value of the dns parameter is the content of the request (as described in dnswire), encoded with base64url RFC4648. </del> <ins> The URI Template defined in this document is processed without any variables when the HTTP method is POST.  When the HTTP method is GET the single variable "dns" is defined as the content of the request (as described in dnswire), encoded with base64url RFC4648. </ins> Future specifications for new media types MUST define the variables used for URI Template processing with this protocol.

Discussion:
dns request clarified in b2a7c6c43f3003e8b56aad62822592c5acf04cdb
From Star Brilliant on the DOH WG mailing list: Issue 1: I found the phrase "URI template" is spelled with a lower "t", where all other occurrences of this phrase is spelled with an upper "T". Is this a typo? Issue 2: I suggest we change the word "and" in Line 2 to "or", for the reason that an HTTP request could not be both GET and POST.
Change:
fields, or a truncated Supported Version. Version Negotiation packets do not use integrity or confidentiality <del> protection.  A specific QUIC version might authenticate the packet as part of its connection establishment process. </del> <ins> protection.  Specific QUIC versions define mechanisms to authenticate the packet as part of the connection establishment process. </ins> An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID

Discussion:
My WGLC feedback for -invariants is mostly nits, so I figured I'd go straight to a PR. There's one piece of this that might be non-editorial; feel free to kick to an issue if you prefer. In one section, we say that different versions "might" define authentication for VN packets. Later, we say that QUIC versions MUST define such a mechanism. Resolving in favor of the MUST, I've changed the other occurrence to a more definitive statement that QUIC versions do so.
Thanks Mike.
Change:
6. <del> The security considerations of DetNet in general are discussed in RFC8655 and I-D.ietf-detnet-security.  DetNet IP data plane specific considerations are summarized in I-D.ietf-detnet-ip.  Encryption may provided by an underlying sub-net using MACSec IEEE802.1AE-2018 for DetNet IP over TSN flows. </del> <ins> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet MPLS data plane specific considerations are summarized in I-D.ietf-detnet-mpls.  This section considers exclusively security considerations which are specific to the DetNet MPLS over TSN sub-network scenario. The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/ TSN services are provided by a sub-network may supply information that can be used in a variety of security attacks.  The ability to modify information exchanges between connected DetNet nodes may result in bogus operations.  Therefore, it is important that the interface between DetNet nodes and TSN sub-network are subject to authorization, authentication, and encryption. The TSN sub-network operates at Layer-2 so various security mechanisms defined by IEEE can be used to secure the connection between the DetNet nodes (e.g., encryption may be provided using MACSec IEEE802.1AE-2018). </ins> 7.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
7.4. When DTMF is sent with RFC4733, it is end-to-end encrypted and the <del> relay can not read it so it can not be used to control the relay. </del> <ins> relay can not read it so it cannot be used to control the relay. </ins> Other out of band methods to control the relay need to be used instead.

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
based data serialization language designed around the common native data types of dynamic programming languages. <del> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias node application-yaml-fragment.  A fragment identifier starting with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). </del> <ins> See </ins> Additional information:

Discussion:
includes clarification on JSON Pointer and alias nodes compatibility includes FAQ fragment identifier moved from media type to section empty fragment + are both under JSON Pointer
cc: NAME NAME PTAL
According to NAME this PR should better clarify JSON Pointer use, so I am going to merge it. The decision on forcing +yaml fragment is deferred to that I will rebase.
Change:
numbers is not required, then an implementation MAY include just the lower 32 bits of the data sequence number in the data sequence mapping and/or Data ACK as an optimization, and an implementation can <del> make this choice independently for each packet.  An implementaton </del> <ins> make this choice independently for each packet.  An implementation </ins> MUST be able to receive and process both 64-bit or 32-bit sequence number values, but it is not required that an implementation is able to send both.

Discussion:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.