jiebi/CodeConvo huggingface dataset:
Change:
Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). <del> 2.4. </del> <ins> 2.3. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping

Discussion:
Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).
Change:
8.2. <ins> The following example shows how to connect a branch office network to a corporate network such that all machines on those networks can communicate.  In this example, the IP proxying client is attached to the branch office network 192.0.2.0/24, and the IP proxy is attached to the corporate network 203.0.113.0/24.  There are legacy clients on the branch office network that only allow maintenance request from machines on their subnet, so the IP Proxy is provisioned with an IP address from that subnet. In this case, the client does not specify any scope in its request. The IP proxy assigns the client an IPv4 address (203.0.113.100) and a split-tunnel route to the corporate network (203.0.113.0/24).  The client assigns the IP proxy an IPv4 address (192.0.2.200) and a split-tunnel route to the branch office network (192.0.2.0/24).  This allows hosts on both networks to communicate with each other, and allows the IP proxy to perform maintenance on legacy hosts in the branch office. 8.3. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to target.example.com using SCTP (IP protocol 132), and receives a

Discussion:
This is an editorial PR based on comments made by Chris Wood during his shepherd review of the document.
Change:
7.7. A sender becomes idle if it ceases to send data and has no bytes in <del> flight.  A sender's congestion window MUST not increase while it is </del> <ins> flight.  A sender's congestion window MUST NOT increase while it is </ins> idle. When sending data after becoming idle, a sender MUST reset its

Discussion:
I think "MUST NOT" was the intention of , not "MUST not".
NAME you can just merge these.
Change:
3.2.1. <del> The Captive Network MUST associate the User Equipment with an </del> <ins> The Captive Portal MUST associate the User Equipment with an </ins> identifier that is unique among the User Equipment that are <del> interacting with the Captive Network at that time. </del> <ins> interacting with the Captive Portal at that time. </ins> Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures

Discussion:
A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal aligns more closely with familiar use of the term. Further, other documents such as the API draft refer to the system as a whole as a Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash writes: I think that this is clear: one is a network and the other a server. Review to see if the right choice is used throughout. URL point out that we assume a degree of mutual control over both.
Change:
entity like the LTP described above.  Moreover, a TTP can terminate one or several OTSiG signals (tunnels) as described in I-D.ietf-teas- te-topo-and-tunnel-modeling and each OTSiG consists of one or <del> multiple OTSi signals as described in sect-2.3.2.  Therefore, a TTP may be associated with multiple transceiver modules. </del> <ins> multiple OTSi signals as described in OTSiG.  Therefore, a TTP may be associated with multiple transceiver modules. </ins> A transponder is typically characterized by its data/symbol rate and the maximum distance the signal can travel.  Other transponder

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass
Change:
9. If the client and server have negotiated the "connection_id" <del> extension DTLS-CID, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </del> <ins> extension I-D.ietf-tls-dtls-connection-id, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </ins> %%% Connection ID Management enum { cid_immediate(0), cid_spare(1), (255) } ConnectionIdUsage;

Discussion:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.
Change:
Only the UTF-8 form of JSON is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159. <del> Characters in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. </del> <ins> Octets in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. </ins> Systems receiving measurements MUST be able to process the range of floating point numbers that are representable as an IEEE double

Discussion:
I think that the current SenML draft is missing a note on JSON/CBOR differences in Data Value: While it is explicitly stated that vd is a base64 string in JSON and a binary-value in CBOR, the supposedly exhaustive list of differences in 6. fails to mention that no base64 encoding is done in CBOR. Suggested addition: o For Data Values, no base64url-encoding is done, as the data can be directly expressed as binary-value. Furthermore, I suggest that "Characters in the Data Value are base64 encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", to make the distinction to the character-based strings and binary data clearer. (The only context in which I'd name bytes of binary data "Character" are when speaking of a "char" in C). Best regards Christian
Indeed, characters should be called characters, and bytes should be called bytes. (In C, bytes are represented as uint8_t :-). s/can be/are/ (they are!)
Have a read of the PR I put in for this. I think it resolves the issue
Looks good to me (with the one typo fix)
typo fix
Change:
A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes by adding PADDING frames to the Initial packet or <del> by coalescing the Initial packet; see packet-coalesce.  Similarly, a server MUST expand the payload of all UDP datagrams carrying ack- eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes.  Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions.  Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </del> <ins> by coalescing the Initial packet; see packet-coalesce.  Initial packets can even be coalesced with invalid packets, which a receiver will discard.  Similarly, a server MUST expand the payload of all UDP datagrams carrying ack-eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes. Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions.  Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address- validation. </ins> Datagrams containing Initial packets MAY exceed 1200 bytes if the sender believes that the network path and peer both support the size

Discussion:
This seems to have caused problems, so address it.
This text in seems to cause confusion for implementors: since it leaves it unclear what the Initial packet can be coalesced with to pad it. Specifically, some implementations use zeros or other (random) data, which seems to surprise some implementors. (, which is referred to, also doesn't seem to clarify this.)
My understanding is that transport draft does not say anything about padding outside QUIC packet. Because a receiver is required to ignore invalid long packets, zero padding outside QUIC packet just works. So this is "OK because it is not explicitly disallowed" category.
I agree, but it has tripped up implementers (again). I wonder if a wording can be found that doesn't do that.
I'd be happy to see a bit more explicit text to clarify this, since as you said, it's come up a few times as non-obvious.
Maybe something like: "An Initial that is padded by coalescing could be coalesced with valid or even invalid QUIC packets; the latter MUST be ignored as described in Section XYZ."
Change:
algorithm. All algorithm configurations can have a server ID length, nonce <del> length, and key.  However, for Plaintext CID, the key is not used and the nonce length is always zero.  For Block Cipher CID, the nonce length is directly computed from the server ID length. </del> <ins> length, and key.  However, for Plaintext CID, there is no key. </ins> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate <del> temporary keys as specified in e.g., RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </del> <ins> temporary keys according to the negotiated ciphersuite, e.g., for X25519 this is done as specified in RFC7748.  This method is referred to as ECDHE, where the last 'E' stands for Ephemeral.  The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for </ins> Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 TS.33.501.

Discussion:
Karl: Why is this "e.g." inserted in section 5? "generate temporary keys as specified in e.g., [RFC7748]" It sounds non-deterministic. If using RFC7748 is an option that can be negotiated or need to be pre-established, then maybe we could write something like: "according to the negotiated ciphersuite, e.g. [7748]." If the sentence is more describing a general way of how one would go about designing FS here, then perhaps something like: "To provide FS, a key exchange must run in an ephemeral manner...".
I think you are right. The text is a bit sloppy (but I don’t think it has changed in a while). I like your first formulation. Once you know the ciphersuite this is all specified & determined.
Will make a PR
Solution merged to the base.
Change:
Using Multicast DNS to protect privacy when exposing ICE candidates <del> draft-ietf-rtcweb-mdns-ice-candidates-latest </del> <ins> draft-ietf-mmusic-mdns-ice-candidates-latest </ins> Abstract

Discussion:
LGTM but travis does not seem happy, not sure why: git -C /tmp/ghpages5574 push -q URL gh-pages 684make: * [ghpages] Error 128
I think the bot doesn't have push credentials on this repo. I'll look into it.
LGTM. The travis failure may render https://rtcweb-URL unavailable but shouldn't impact other parts. I wonder if the failure is caused by name mismatch somewhere in the config.
Change:
[2] https://www.ietf.org/mailman/listinfo/mops [3] https://mailarchive.ietf.org/arch/browse/mops/ <ins> [4] https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [5] https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/ issues/114 </ins>

Discussion:
I made one change to the links, because this gets a 404: URL But a web search for "SCTE-214-1" found this instead, which seems to be a new location for the same thing: URL Additionally, There were 3 more links that failed check-URL URL URL URL All of these get something with chrome, but fail with curl. The datazoom links get a 403 and the iabtechlab gets a 406. (Changing the UA header to match chrome's made curl succeed with iabtechlab, but not the datazoom links. Didn't dig deeper yet.) I haven't put in automation for this, but I figure it's useful to have something at least to do a quick scan.
This works. These work just fine for me on chrome no 403 or 406, plain 200.
They work for me in chrome also, but they don't work in curl or wget so the script complains about them.
Looks good to me, modulo a Github Action error that we don't understand. Will merge now, so we can move forward.
Just make the change for ACM Mile-High Video Conference.
Change:
Optional record digests may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension.  In <del> such settings, servers must perform trial decrypt upon receipt of an empty record digest, which may exacerbate DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </del> <ins> such settings, clients send either an empty record_digest or a randomly generated record_digest in the ClientEncryptedCH.  (The precise implementation choice for this mechanism is out of scope for this document.)  Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key using the record_digest value.  As a result, support for optional record digests may exacerbate DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </ins> 10.4.

Discussion:
As discussed on the list, add a small bit of text in the section 10.3 to outline the behavior of clients seeking to protect server's privacy.
Thanks!
Change:
the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01"). <ins> 10.2. An ACME-based CA needs to make DNS lookups when processing challenges.  Because the security of an ACME-based CA ultimately depends entirely on the authenticity of DNS data, every possible precaution should be taken to secure such lookups.  It is therefore RECOMMENDED that ACME-based CAs make all DNS resolutions via DNSSEC- validating stub or recursive resolvers.  This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed.  It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for all CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). </ins> 11.  References 11.1.  URIs

Discussion:
I approve of this change.
This looks good to me. I would like to tighten up the language a bit to clarify that this applies to validation of DNS identifiers, but will do that in a follow-on PR.
Change:
transport-security, many transport security protocols require specific security parameters and constraints from the client at the time of configuration and actively during a handshake.  These <del> configuration parameters are created as follows: </del> <ins> configuration parameters need to be specified in the pre-connection phase and are created as follows: </ins> Security configuration parameters and sample usage follow:

Discussion:
... while we use (property, values) pairs to set other properties? Is there a reason for this? Otherwise I suggest we agree to one interaction model!
Related I also think this text isn't really that correct: "Security decisions, especially pertaining to trust, are not static. Once configured, parameters may also be supplied during connection establishment. These are best handled as client-provided callbacks." You can update some security parameter anytime during the connection using the same interface as before. However the two callbacks we have defined require actually actions that follow an event, so they have to be callbacks.
"However the two callbacks we have defined require actually actions that follow an event, so they have to be callbacks." - that's it, these need to be callbacks. NAME made them like that because using them requires a tighter interaction model. See issue .
As discussed in interim, Security Parameters are a bit different from selection properties. We should review the security parameter interface, but it will likely be independent.
I did a closer review on these and there are two main differences between Security Parameters and the other Preferences / Events: Use of individual calls on security parameters instead of add with keywor. These could easily be integrated, e.g., by turning into Use of Callbacks instead of Events – closed as Issue . Despite there is no technical reason to not turn the Security Callbacks into events, events that "need to do something", i.e., accept, reject, or return an identity, really look wired. Let's discuss which way to take this one forward: Leave as is Align the interface of SecurityParameters to the Transport Parameters, but keep them as a separate object and leave SecurityCallbacks as they are Integrate the interface of SecurityParameters into the Transport Parameters, but keep SecurityCallbacks roughly the same Integrate the interface of SecurityParameters into the Transport Parameters, make SecurityCallbacks more event-like. I am happy to make a PR for whatever we decide, but not for all of them.
We can do the minor option to change AddCiphersuite to Add(ciphersuite...)
Maybe add clarification text to say that these are pre-connection only parameters
Consider cutting cache lifetime, etc, from this list
We really should explicitly add a sentence to clearly say that the security functions are configured using add functions and not via Properties.

This is so useful to say, so that someone does not come along and do this because they think we just didn't see this.
closed with
lgtm, will let NAME merge it though.
Change:
Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, <ins> Then the encrypted_record field of TLSCiphertext is set to AEADEncrypted. </ins> In order to decrypt and verify, the cipher takes as input the key, <del> nonce, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </del> <ins> nonce, additional data, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </ins> If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.

Discussion:
Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL
Change:
requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between and servers avoids adding significant additional delay due to network topology.  A study <del> of a similar system ODoH found that deploying proxies close to </del> <ins> of a similar system ODOH-PETS found that deploying proxies close to </ins> servers was most effective in minimizing additional latency. 8.2.

Discussion:
Dingledine2004 -> DMS2004 ODoH -> ODOH-PETS
Comment by NAME ODOH and ODoH seems very similar and likely to cause confusion. Rename one?
thanks
Comment by NAME Using "[Dingledine2004]" as description identifier for TOR is a bit weird :P
This is entirely appropriate given the nature of the reference. This is a reference to a paper, not a specification for Tor, so using "[TOR]" could be misleading. It's possible that we could cite a specification, but it's really hard to pin that down properly. URL seems right, but it doesn't bear a date and appears to be a rendering from URL which is in turn just a snapshot (currently URL). Aside from referential stability, the specification is less of a useful reference as it says less about what Tor is and gets buried in detail. I'm inclined to leave as-is, or switch to "[DMS2004]" to reference all author's names.
ok