jiebi/CodeConvo huggingface dataset:
Code change:
This API changes the local media state; among other things, it sets up local resources for sending and encoding media. <del> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), </del> <ins> If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), </ins> and the media directions are compatible, and media are available to send, this will result in the starting of media transmission.

Related discussion:
text: I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me
Code change:
Even when redirected, the User Equipment securely authenticates with API servers. <del> 5.4. </del> <ins> 5.5. </ins> The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do

Related discussion:
text: We want to make TLS a requirement, not a suggestion, so I've chagned the wording around TLS to reflect this. I also added a section to the security section discussing the motivation behind the requirement.
Can you forward to the list please?
Code change:
for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by <del> the same entity. </del> <ins> the same entity or cooperating entities. </ins> 1.

Related discussion:
text: changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.
Code change:
can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction. </del> <ins> Clients MUST ensure that UDP datagrams containing only Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction. </ins> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when

Related discussion:
text: Builds on .
Initial packets need to be in 1200 byte datagrams for DoS amplification reasons. We have an exception for the case where an ACK for a Handshake packet has been received from the peer. In that case, we remove the requirement to pad. That condition is extraordinarily obscure, especially if we are suggesting that endpoints not send any more Initial packets once they have Handshake keys. Removing this text is the right answer.
+1 to the proposed resolution.
Code change:
Closing a single QUIC stream, presented to the application as a Connection, does not imply closing the underlying QUIC connection itself.  Rather, the implementation may choose to close the QUIC <del> connection once all streams have been closed (possibly after some </del> <ins> connection once all streams have been closed (often after some </ins> timeout), or after an individual stream Connection sends an Abort. <del> Messages over a direct QUIC stream should be represented similarly to the TCP stream (one Message per direction, see tcp), unless a framing mapping is used on top of QUIC. </del> <ins> Connectedness: Multiplexing Connected Data Unit: Stream Connection objects represent a single QUIC stream on a QUIC connection. </ins> 9.7.

Related discussion:
text: Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.
Code change:
number of acknowledgments allows connection throughput to scale much further. <del> Unfortunately, there are undesirable consequences to simply reducing the acknowledgement frequency, especially to an arbitrary fixed value, as follows: A sender relies on receipt of acknowledgements to determine the amount of data in flight and to detect losses, see QUIC-RECOVERY. Consequently, how often a receiver sends acknowledgments dictates how long it takes for losses to be detected at the sender. Starting a connection up quickly without inducing excess queue is important for latency reduction, for both short and long flows. The sender often needs more frequent acknowledgments during this phase. Congestion controllers that are purely window based and strictly adherent to packet conservation, such as the one defined in QUIC- RECOVERY, rely on receipt of acknowledgments to move the congestion window forward and release additional data.  Such controllers suffer performance penalties when acknowledgements are not sent frequently enough.  On the other hand, for long-running flows, congestion controllers that are not window-based, such as BBR, can perform well with very few acknowledgements per RTT. New sender startup mechanisms will need a way for the sender to increase the frequency of acknowledgements when fine-grained feedback is required. </del> <ins> As discussed in implementation, there are undesirable consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.  Consequently, a sender needs the ability to express its constraints on the acknowledgement frequency to maximize congestion controller performance. </ins> QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every

Related discussion:
text: NAME NAME I can take a stab at writing something and we can go from there.
Thanks, NAME !
I do think the pitfalls of e.g. should be conveyed in such "cautionary" text as well. I will submit a PR this week time permitting between interop.
Thanks, NAME
Code change:
"encrypted_extensions", "end_of_early_data", "key_update", and "handshake_hash" values. <del> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its allocation policy is listed below: </del> <ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document. The registry and its allocation policy is listed below: </ins> IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes",

Related discussion:
text: Need to be explicit say that it's the ExtensionType registry from RFC 4366.
I literally was making the same change in my editor when the notification came in! (Should it be the "TLS Extensions ExtensionType registry"?)
Code change:
12.2. A group member creating a commit and a group member processing a <del> commit MUST verify that the list of committed proposals is valid </del> <ins> Commit MUST verify that the list of committed proposals is valid </ins> using one of the following procedures, depending on whether the <del> commit is external or not. </del> <ins> commit is external or not.  If the list of proposals is invalid, then the Commit message MUST be rejected as invalid. </ins> For a regular, i.e. not external, commit the list is invalid if any of the following occurs:

Related discussion:
text: URL This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session. Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text. To improve clarity, consider defining these key terms. The use of "respectively" in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. (see the Cryptographic Dependencies section of the HPKE specification for more information). Is this Section 4 of RFC9180?  If so, why not say that? What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a "MUST"? Unsaid is what to do if the proposal list is not valid.  Please clarify. Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this "recovery from an invalid node" may not be consistent across clients/DS-es. Same observation on recovering from ReInit with any other proposals. Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely? This setup seems a little simplistic. If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?
Code change:
one ep (endpoint with a unique name) <del> one con (a string describing the scheme://authority part) </del> <ins> one con (a string typically describing the scheme://authority part) </ins> one lt (lifetime),

Related discussion:
text: This allows for gateway devices that register their mapped legacy devices individually. Closes: URL The delta is smaller than I expected because at some places, paths were already allowed (eg. in the IANA table for "con"). One place where I'm unsure if we should change it because I don't know what it actually means is the "scheme, IP, port" annotation in fig-hierarchy -- what does it mean there?
what is a path no scheme form? An example might help here.
path-noscheme form is one of the possible ABNF forms for a relative reference from ; it basically means "relative references that does not even start with a slash". I'm conflicted about having an example in the draft (our examples already feel like a test suite), but I'll give one here and we can still consider moving it in: ~
Merging this with a clarification for the ABNF item, so we have a single version to talk about later today.
I'm aware this is a discussion we've already had, but back then we dropped it for its complexity and because we had no use cases. Matthias has brought up use cases for allowing a path in the con as part of the -13 reviews. He argues that a gateway bridging into a non-CoAP world would want to register its proxees (is that a word?) individually, and if it doesn't use name-based virtual hosting (which is kind of rare in CoAP and needs wildcard DNS records), could go for path-based hosting. As I see it, this would be a trivial addition from the RD point of view ("just allow it"). The onus is on the endpoint / gateway to do it right, ie. to never use path-absolute URI references unless they mean it. What does make this a bit more complicated is that none of the content formats we currently describe allows using that meaningfully -- but we are not limiting the RD to those content formats, and they may (and hopefully will) still change while we're finishing RD. On the editing track, I would keep those cases out of the examples (I'm game for building a test suite, but the examples shouldn't be that). Then, the editing becomes a matter of replacing "specified URI MUST NOT have a path component" with "typically does not have a path component", adding the one or the other "typically", and being done with it.
Code change:
one ep (endpoint with a unique name) <del> one con (a string describing the scheme://authority part) </del> <ins> one con (a string typically describing the scheme://authority part) </ins> one lt (lifetime),

Related discussion:
text: (This would also make URL obsolete, as those components would be allowed). NAME (and possibly NAME I'd assume you won't be too happy with (based on previous discussions of that topic), but do you see Matthias' point, or could point out concrete issues you see from allowing this?
I would prefer that not be made obsolete on this. You should be able to have a URI w/ a path and a relative URI which are then combined. If we need to combine things like query parameters then it is going to get really messy really fast because there are not good rules about that. I don't have any problems w/ allowing for the con to have a path and resolving with it. I just think that we need to establish what the rules are in the RD document rather than using the horrible link format rules.
There are very good rules about that query parts and fragments in the Base URI: Anything that is not an empty string or starts with a "#" removes the fragment identifier and the query parameters. The Base URI's fragment identifier is never kept. (Derived from RFC3986 Section 5.2). I'll try to write text on this issue on the weekend (NAME a "no we can't have that because" would be more appreciated today than later), let's talk about again when we have that. Dear list RD allows the "con" parameter to provide a base URI for relative resource URIs, when the registration is done from a different source address then the registered endpoint itself. "con" is restricted to the scheme and authority part of a URI, that is, no path segments are allowed. This came from the assumption that all CoRE devices will naturally correlate with socket-address endpoints. However, a registered device(=endpoint, "ep") might not be a natural endpoint. When using gateways or device proxies, the base URI will have path segments and multiple logically different endpoints will share the same socket-address (e.g., URL, URL, URL). This makes it expensive to move such logical endpoints, as updating "con" will not help. All links have to be removed, changed to the new prefix, and registered anew. This is a problem for some applications (including a bigger alliance using CoAP), in particular because the patch mechanism is still to be defined - yet rewriting URI prefixes still will not be really efficient even when having patch registration updates.
Code change:
one ep (endpoint with a unique name) <del> one con (a string describing the scheme://authority part) </del> <ins> one con (a string typically describing the scheme://authority part) </ins> one lt (lifetime),

Related discussion:
text: I thus propose to generalize "con" to be any base URI that will be applied to all relative links an endpoint registered. If there is a conflict with a deployed mechanism, we could look into adopting "anchor" and let RD use it similarly to "con", but allowing full base URIs (including paths). Or we align with RFC 8288 altogether and replace "con" with "anchor": URL Ciao, Matthias
Code change:
receiving the response to its IP proxying request, noting however that those may not be processed by the proxy if it responds to the request with a failure, or if the datagrams are received by the proxy <del> before the request. </del> <ins> before the request.  Since receiving addresses and routes is required in order to know that a packet can be sent through the tunnel, such optimistic packets might be dropped by the proxy if it chooses to provide different addressing or routing information than what the client assumed. </ins> When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local

Related discussion:
text: NAME let's discuss that on . I'd like to merge this PR first then decide on a plan for before submitting the next revision to the datatracker
Splitting {ADDRESSREQUESTROUTEADVERTISEMENT} into ...V4 and ..._V6 would result in smaller capsules that have fewer error conditions. It would also keep IPv4 and IPv6 logic distinct.
I don't think the size of these capsules matters given their rarity. I can see the error condition argument but it's pretty minor and would come at the cost of making the specification longer. I don't feel too strongly here, but I think I have a slight preference for keeping things as they are.
I agree with David that size is problem not a big concern. I think having one set of capsule is less complex.
I also have a preference for keeping the capsules as they are with versions included; it also allows the route advertisement capsule to include routes for both v4 and v6 in one capsule, which I think is very important. I wouldn't want to lose that feature.
I similarly have a preference for keeping v4 and v6 in one capsule and agree size is not a big concern.
I just chatted with NAME to see what error conditions he was thinking of. Upon discussion (v6 route advertised when only v4 address is available), we concluded that this is not an error case, it's just a route that's not yet usable. We've concluded that this is something that we're comfortable leaving as-is.
Implementing this on the client I was wondering if there should be a way for the client to ask for the server for an address without specifying what address it wants. This could allow a VPN client to mention that it wants an IPv6 address or not. If we think this could be useful, we could encode it as or .
I believe asking for the Any address is what we discussed previously, so +1
You mean ADDRESS_REQUEST(IPv4-0.0.0.0/32) don't you. I think the format of the request works fine. But we do need to before we implement this into the specification.
Yes — if we have this, one option is to always have an ADDRESS_REQUEST expected from clients, and then there doesn't need to be signaling. Or we do the simple solution to 54 to say "I expect to send N capsules with my request".
Code change:
receiving the response to its IP proxying request, noting however that those may not be processed by the proxy if it responds to the request with a failure, or if the datagrams are received by the proxy <del> before the request. </del> <ins> before the request.  Since receiving addresses and routes is required in order to know that a packet can be sent through the tunnel, such optimistic packets might be dropped by the proxy if it chooses to provide different addressing or routing information than what the client assumed. </ins> When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local

Related discussion:
text: You're right this could be a potential solution to . Let's discuss them together tomorrow
Regarding IPv6, I think a standard request that would make sense is asking for any /64. I guess that works fine with this idea too?
Oh that's interesting, if the IP Address is or , the prefix length is a hint for the requested length. I like that.
IETF 114: Add an editorial sentence to "remember, what you ask for may not be what you get, especially with regards to address families". A request should be paired with a response, multiple requests can just say "you have the same ones you had before". Clarify that it's cumulative. Also solves unassign/removal of addresses.
So there appear to exist some downside with the timing of the interactions when one want to use Address-Request capsule. So the basic problem is simply that the proxy will assign an address prior to the Address-Request capsule has been received, thus preventing the proxy from processing the request in the right context. So lets assume that the client has already created one connect-IP request with a limited scope and been assigned IP-A. Then it want to make an additional request for another limited scope proxying and would like to get the same address assigned. Due to the separation between the HTTP request for the Connect-IP and the capsule Address-Request a server can actually process the whole HTTP request prior to receiving the Address-Request. Resulting potentially in that another IP address assignment (IP-B) be provided to the client, despite it asking for IP-A to be assigned also to the request. So does the HTTP request needs an indicator parameter to tell the proxy to wait for one or more "request" capsules from the client before processing the request?
Out of curiosity, in what scenario would the client "like to get the same address assigned"? It makes sense for the proxy to decide to reuse addresses to save its address pool when the scoping allows it, but why would the client care?
I could imagine this happening if the client was trying to resume some previous session that it lost due to an outage? Seems to be niche, but it's certainly possible.
So the most obvious use case for this is to request iproto= CMP in combination with for example UDP.