jiebi/CodeConvo huggingface dataset:
Change:
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP implementations MUST <del> follow the following rules when processing the media m= sections in an offer: </del> <ins> follow the following rules when processing the media m= sections in a received offer: </ins> <del> The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. </del> <ins> Any profile in the offer matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP|TCP)/TLS/RTP/SAVP[F]". </ins> <del> Any profile matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" </del> <ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer. </ins> Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of one

Discussion:
Proposal for how to clarify that when JSEP implementation generates an answer it needs to have the proto value identical to what is in the offer.
NAME do you want to take a look at this one?
BLOCKER: The first bullet on page 35 has a normative statement about the AVT profile strings that must be accepted, but uses an unspecified grammar to actually specify the string. If this is normative, it needs to be formal. Either specify the string using a formal and cited grammar, or provide an exhaustive list.
Proposal on editor's call is to use POSIX extended regular expressions. URL I believe this would give us the expressions. (UDP|TCP)/TLS/RTP/SAVPF? and: RTP/S?AVPF?
You're sure you want to pull in another reference for regexes instead of just listing all eight valid values?
I suggest we merge this without dealing with the formal grammar issue.
Change:
alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet <del> frames within a secure tunnel and can run over UDP or TCP.  For key establishment, OpenVPN can use TLS as a handshake protocol or pre- shared keys. </del> <ins> frames within a secure tunnel and can run over either UDP or TCP. For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. </ins> 4.

Discussion:
Addresses
No objection, but I don't know OpenVPN.
Comment from Ekr's review of -10: Packet Security Protocols: o OpenVPN Well, sort of. OpenVPN needs TCP for its key establishment phase but not its transport phase. That doesn't seem like that interesting a point to make here, as if TCP wasn't available, it could just cut over to DTLS.
Agreed: My notes on OpenVPN say that it can run completely over UDP, in which case it provides its own reliability layer for handshake and key exchange, and no reliability for data packets. I guess that means that OpenVPN does not have any transport dependencies, so deleting it from Section 4.1 is correct and I don't see any other place in Section 4 for it. I'd say stating it can run over either TCP or UDP is enough here, so this PR is sufficient.
Change:
ratchet tree and generate the "commit_secret": Apply the UpdatePath to the tree, as described in <del> synchronizing-views-of-the-tree, and store "key_package" at the Committer's leaf. </del> <ins> synchronizing-views-of-the-tree, and store "leaf_key_package" at the Committer's leaf. </ins> Verify that the KeyPackage has a "parent_hash" extension and that its value matches the new parent of the sender's leaf

Discussion:
It looks like in Commit was moved to in UpdatePath, but some docs didn't get updated.
Change:
highest available capacity, based on the observed maximum throughput. <del> Implementations process the Properties in the following order: Prohibit, Require, Prefer, Avoid.  If Selection Properties contain any prohibited properties, the implementation should first purge branches containing nodes with these properties.  For required properties, it should only keep branches that satisfy these requirements.  Finally, it should order the branches according to the preferred properties, and finally use any avoided properties as a tiebreaker.  When ordering branches, an implementation can give more weight to properties that the application has explicitly set, than to the properties that are default. </del> <ins> Implementations process the Properties (Section 6.2 of I-D.ietf-taps- interface) in the following order: Prohibit, Require, Prefer, Avoid. If Selection Properties contain any prohibited properties, the implementation should first purge branches containing nodes with these properties.  For required properties, it should only keep branches that satisfy these requirements.  Finally, it should order the branches according to the preferred properties, and finally use any avoided properties as a tiebreaker.  When ordering branches, an implementation can give more weight to properties that the application has explicitly set, than to the properties that are default. </ins> The available protocols and paths on a specific system and in a specific context can change; therefore, the result of sorting and the

Discussion:
Quoting from the end of the Section 4 overview, the earliest point in the Implementation Draft where Preference Levels are explicitly mentioned: While the capitalization of "Prohibit" and "Require" does somewhat help to indicate their role as a special term, the sentence does not scan particularly well to any reader that is yet unfamiliar with the notion of Preference Levels from the API draft. At the very least it would help to better contextualize the sentence. Suggestion 1: It could also help to not explicitly refer to any Preference Levels yet. Suggestion 2: This could be sufficient for the Section 4 overview, since Section 4.1.3 "Sorting Branches" later goes into more detail about the different properties and their handling, even if the wording is a bit terse:
Change:
can help monitoring power generation and power demands, and making electrical energy storage decisions in the Smart grid system. <del> 7.2.3. </del> <ins> 6.2.3. </ins> The Water system is one of the most important aspects for building smart city.  Effective use of water, and cost-effective and

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:
IKEv2 <del> Pre-Shared Key Export: The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </del> <ins> Shared Secret Export: The handshake protocol may provide an interface for producing shared secrets for application-specific uses. TLS DTLS tcpcrypt </ins> <del> Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, IKEv2, OpenVPN </del> <ins> IKEv2 </ins> <del> Direct export: TLS, DTLS, MinimalT </del> <ins> OpenVPN </ins> <del> Non-exportable: CurveCP </del> <ins> MinimalT </ins> Key Expiration: The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based

Discussion:
Oh, and just double-checking: For PSK Export, SRTP and QUIC are a "No"? Because the old text said "TLS (for QUIC), DTLS (for SRTP)".
Yeah, I think that since QUIC and SRTP themselves don't export, but just use the export from inner protocols, this makes sense as is.
Comment from Ekr's review of -10: I'm not following any of the text around import. This direct/explicit distinction seems arbitrary, and weird for QUIC, because QUIC doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated.
NAME can you help on this one?
Ping NAME
We can do this for the export side of things, too.
Fixed in .
Thanks, looks good! Just suggesting one tweak in the wording for the import text.
Change:
Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This is a fatal error. </del> <ins> parameters given the options available.  This message is always fatal. </ins> This alert was used in SSLv3 but not any version of TLS.  It MUST

Discussion:
I have seen multiple implementations with messages marked as warning instead of fatal.. It might be more explicit this way ? B.
I like this because some folks never read the text they just look at the code.
Change:
of 15 seconds, but recommends larger values, or omitting keepalive entirely. <del> By using a Connection ID, QUIC is designed to be robust to NAT </del> <ins> By using a connection ID, QUIC is designed to be robust to NAT </ins> address rebinding after a timeout.  However, this only helps if one endpoint maintains availability at the address its peer uses, and the peer is the one to send after the timeout occurs.

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
Ultra low-latency delivery of media is defined here as having a glass-to-glass delay target under one second. <del> This level of latency is sometimes necessary for real-time interactive applications such as video conferencing, operation of remote control devices or vehicles, or remotely hosted real-time gaming systems.  Some media content providers aim to achieve this level of latency for live media events involving sports, but have usually so far been unsuccessful over the internet at scale, though it is often possible within a localized environment with a controlled network, such as inside a specific venue connected to the event. Applications operating in this domain that encounter transient network events such as loss or reordering of some packets often experience user-visible artifacts in the media. </del> <ins> Some media content providers aim to achieve this level of latency for live media events.  This introduces new challenges relative to less- restricted levels of latency requirements because this latency is the same scale as commonly observed end-to-end network latency variation (for example, due to effects such as bufferbloat, Wi-Fi error correction, or packet reordering).  These effects can make it difficult to achieve this level of latency for the general case, and may require tradeoffs in relatively frequent user-visible media artifacts.  However, for controlled environments or targeted networks that provide mitigations against such effects, this level of latency is potentially achievable with the right provisioning. </ins> Applications requiring ultra low latency for media delivery are usually tightly constrained on the available choices for media

Discussion:
Yes, lets add it. Well, I really don't want to imply that right provisioning requires QoS or at least some DSCP marking. Yes, to many, the answer could be just providing enough bandwidth for others, it could be a bit more complicated. If you have seen my recent ANRW talk, I refer to the "QoS" as the first camp (slide 5) and many efforts to date simply failed in that aspect. Paper: URL Slides: URL
I like this text. I have thoughts. Do we need a reference for "bufferbloat"? We haven't used that term in the document yet, and I agree with using it here. I note . I agree with "the right provisioning", but for someone not skilled in the art, that may be like "and then a miracle occurs", and I suspect a lot of people still assume "the right provisioning" means something like "the right bandwidth provisioning", which isn't what we mean at all, is it? ISTM that we might (1) mention DSCP, (2) mention URL as something to be aware of.
Change:
transmitted on a stream.  For a stream that is reset, the final offset is carried explicitly in a RESET_STREAM frame.  Otherwise, the final offset is the offset of the end of the data carried in a STREAM <del> frame marked with a FIN flag, or 0 in the case of incoming unidirectional streams. </del> <ins> frame marked with a FIN flag. </ins> An endpoint will know the final offset for a stream when the receiving part of the stream enters the "Size Known" or "Reset Recvd"

Discussion:
I think the text is a leftover from time before we introduced STOP_SENDING.
There was an earlier draft where RST could be used for both locally and peer initiated streams. Not sure if that is relevant here.
Change:
available), the use of a preconfigured anycast address is recommended (e.g. installation phase described in automation). <del> The use of DNS facilities is described in I-D.ietf-core-rd-dns-sd. </del> <ins> In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. </ins> The use of multicast discovery in mesh networks is NOT recommended.

Discussion:
This was missed in the original pull of mechanism from RD-DNS-SD into here; its wording was brought in line with the other recommendations ("In case X, Y is recommended") and now goes to the internal section rather than the external document. Will be merged on Monday before submission unless spoken against.
Change:
20. <del> QUIC error codes are 62-bit unsigned integers. </del> <ins> QUIC transport error codes and application error codes are 62-bit unsigned integers. 20.1. </ins> This section lists the defined QUIC transport error codes that may be <del> used in a CONNECTION_CLOSE frame.  These errors apply to the entire connection. </del> <ins> used in a CONNECTION_CLOSE frame with a type of 0x1c.  These errors apply to the entire connection. </ins> An endpoint uses this with CONNECTION_CLOSE to signal that the connection is being closed abruptly in the absence of any error.

Discussion:
The current structure is incorrect, because application error codes is a subsection of transport error codes, despite application error codes being disjoint from transport error codes.
Wonderful. Thank you.
Change:
access token, the client instance MUST present both the new key and previous key in the access token rotation request.  The client instance makes an HTTP POST as a JSON object with the following <del> fields: </del> <ins> field: </ins> The "proof" method and parameters for the new key MUST be the same as those established for the previous key. <del> The client instance MUST prove possession of both keys simultaneously in the rotation request.  The means of doing so varies depending on the proofing method in use.  For example, the HTTP Message Signatures proofing method uses multiple signatures in the request as described in httpsig-rotate, as shown in this example. </del> <ins> The client instance MUST prove possession of both the currently-bound key and the newly-requested key simultaneously in the rotation request.  Specifically, the signature from the previous key MUST cover the value or reference of the new key, and the signature of the new key MUST cover the signature value of the old key.  The means of doing so varies depending on the proofing method in use.  For example, the HTTP Message Signatures proofing method uses multiple signatures in the request as described in httpsig-rotate, as shown in this example. </ins> An attempt to change the "proof" method or parameters, including an attempt to rotate the key of a bearer token (which has no key), MUST

Discussion:
To edit notification comments on pull requests, go to your .
The "previous_key" element added in is not necessary in practice because the AS should always be able to look up the current key value based on the access token, and the signature using the previous key proves possession of that key separate from any presentation of the key value or reference.
Makes sense
Change:
All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The <del> length MUST NOT exceed 2^14. </del> <ins> length MUST NOT exceed 2^14.  This field is of type uint16. </ins> 6.

Discussion:
To address URL
Thanks! This PR fixes the missing size of the introduced length.
I miss the hint for the size of . I would assume it's a 2 bytes value. Is that right? Is this information already in the document and have overseen it? Both introduce a special "length" and use different approaches to do so. One with extra definition, one with a included definition. Is this intended?
Fixed with
Change:
Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. <del> However, even if clients do offer it, the rules specified in TLSEXT </del> <ins> However, even if clients do offer it, the rules specified in RFC6066 </ins> require servers to ignore extensions they do not understand. Servers MUST NOT send this extension.  TLS servers MUST support

Discussion:
The TLS 1.2 RFC cited WIP extension definitions at time of publish. Update current draft to point the final RFC 6066.
URL Fix merged. This should be closable now.
Change:
17. <del> The authors are fairly certain that there are no security considerations for this document. </del> <ins> The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported groups.  This was espcecially true of national cipher suites. </ins> 18.

Discussion:
Possibly addresses .
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.
Change:
Version Negotiation packets are used by the server to indicate that a requested version from the client is not supported (see Section 6 of QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically <del> protected, but future QUIC versions will use later encrypted messages to verify that they were authentic.  Therefore, any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </del> <ins> protected, but future QUIC versions could use later encrypted messages to verify that they were authentic.  Therefore, any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </ins> Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid

Discussion:
Currently the document uses "will". This might be a very valid assumption, but still it is an assumption hence I think it is better to use "May" instead of "Will".
Change:
For Connections that are Establishing: Transport Properties that the application specified on the Preconnection, see connection- <del> props.  Selection Properties of a Connection can only be queried, not set. </del> <ins> props. </ins> For Connections that are Established, Closing, or Closed (TODO: double-check if closed belongs here): Transport Properties of the

Discussion:
Rather than saying "this can only be queried" everywhere, I split this into setting and querying now, and I also moved SoftErrors in there. It's not precisely "querying" for a Property, but it's the closest match - better than "Connection Termination", I think (this is where SoftErrors were before).
NAME what about "Connection Maintenance: Setting Properties and Obtaining Information" ?
Maintenance sounds a bit strange to me, "Managing Connections: Setting Properties and Obtaining Information" ?
I like it (and I agree about "maintenance" being slightly strange)
Managing sounds good to me too.
Ack, done
lgtm, thanks!
Change:
"index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays. <del> Note that there is no "bald" descendant selector (".." on its own). </del> <ins> Note that ".." on its own is not a valid selector. </ins> 3.5.7.2.

Discussion:
Fixes URL
Let's continue in URL
Currently the syntax section of the "Filter Selector" section describes some semantics. These descriptions should be folded into the semantics section.
I'm not sure we are done with this yet. See comments.The reordering looks good to me.
Change:
connection ID for the lifetime of the connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See <del> Section 6.1 of QUIC-TRANSPORT. </del> <ins> Section 5.1 of QUIC-TRANSPORT. </ins> 2.7.

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.
Change:
Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node. <del> Update the new GroupContexts confirmed and interim transcript </del> <ins> If the "path" value is not populated: Define "commit_secret" as the all-zero vector of the same length as a "path_secret" value would be. Update the new GroupContext's confirmed and interim transcript </ins> hashes using the new Commit. Use the "commit_secret", the provisional GroupContext, and the

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.