jiebi/CodeConvo huggingface dataset:
Change:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-08 </del> <ins> draft-ietf-rtcweb-transports-09 </ins> Abstract

Discussion:
LGTM with comment above.
I think we should just refer people to 5763, S 6.7.1: Interactive Connectivity Establishment (ICE), as specified in [RFC5245], provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream. Specifically, I think we should say: Note: DTLS-SRTP as defined in defines how DTLS interacts with ICE in Section 6.7.1. As indicated therein, implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs.
Rephrased according to Justin's suggestion.
Change:
The named parameters are: "task_id", the DAP task ID.  If the Leader does not recognize the <del> task ID, it MUST abort with HTTP status code 400 Bad Request and error "unrecognizedTask". </del> <ins> task ID, it MUST abort with error "unrecognizedTask". </ins> "query", the Collector's query.  The indicated query type MUST match the task's query type.  Otherwise, the Leader MUST abort

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged
Change:
data set, because There may not be a tree that covers the directed graph, or the <del> tree's root may not be the URI from which the document is obtained. </del> <ins> tree's root may not be the retrieval context. </ins> There may be multiple edges into a blank node. In particular, the precise data from one structured information <del> document can only be expressed with the same root node.  However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the </del> <ins> document can only be expressed with the same retrieval context. However, statements can be added to make a data set that is expressible elsewhere (this document defines the "carries- information-about" relation type leading to the </ins> "http://www.iana.org/assignments/relation/carries-information-about" predicate being usable here), and subsets of the data can be taken and expressed.

Discussion:
Closes: URL This builds on
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).
Change:
5.2.12. <ins> local-address-preference Enumeration This property specifies whether Listeners and Connections should prefer the use of temporary addresses when possible.  This is generally used to prevent linking connections over time when a stable address is not needed.  Possible values are: Prefer the use of stable (sometimes called "permanent") local addresses Prefer the use of temporary (sometimes called "privacy") addresses Prefer the use of stable local addresses for Listeners and Rendezvous Connections, and prefer the use of temporary addresses for other Connections. 5.2.13. </ins> multipath This property specifies whether an application considers it useful to

Discussion:
Address
API should allow a preconnection property to specify if a private (IPv6) address is preferred. Outbound connections should prefer this. Listeners should avoid this.
Thank you! I was really missing this one .LGTM!
Change:
IANA is to add the following to the TLS ExtensionType Values registry: <ins> The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. These are not applicable to DTLS 1.3. </ins> 15. To make it clear that (D)TLS 1.3 has orphaned certain registries

Discussion:
I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.
Change:
Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential <del> is no longer valid.  Endpoints will reject delegate credentials with valid_times exceeding 7 days (as described in client-and- server-behavior). </del> <ins> is no longer valid.  Endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in client-and-server-behavior). </ins> The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be

Discussion:
Update the condition for validating a DC to the following: now() <= notBefore + valid_time <= now() + 7d
LGTM % nit
Change:
MUST contain all "m=" sections that were previously bundled, as long as they are still alive, as well as any new "m=" sections. <ins> Note that if bundling has been negotiated, unbundling is no longer possible, and media sections will not be marked as bundle-only.  This is by design, but could cause issues in the rare case of sending a subsequent offer as an initial offer to a non-bundle-aware endpoint via Third Party Call Control (3PCC). </ins> "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and

Discussion:
This includes the changes requested at IETF 111 (summarized in URL), which are: modified text in S 1.3 (requested by NAME to spell out that "must-bundle" is the behavior formerly known as "max-bundle" added brief discussion of interaction of BUNDLE and TPCC (requested by NAME
FYI NAME
LGTM.
Should we add a reference to rfc8843bis? The rest looks good.
LGTMLGTM
Change:
the original request was never retransmitted, <del> the response was piggybacked in an Acknowledgement message (a confirmable response may have been transmitted multiple times), and </del> <ins> the response was piggybacked in an Acknowledgement message (as a confirmable or non-confirmable response may have been transmitted multiple times), and </ins> if observation was used, the same holds for the registration, all re-registrations, and the cancellation.

Discussion:
This is my take on , pointing to the cases when it's possible to reuse tokens, at the same time discouraging it for all other cases. The acceptable cases are the ones identified in the last authors' call, and TLS and OSCORE I've added in a potential third case in source comments; it's still something we can dig up if people ask for more comprehensive exceptions, but there's so many things that can go wrong that I'd rather not have it in.
Thanks, merged. I did put in a clarification on the f81c97221a1f0e7571ad06811a8b713659741336 edit -- acutally both CON and NON would be unusable.
I tried to add security considerations for token reuse to the PR. Please review, this is not trivial. Token reuse for DTLS seem hard if not impossible to do securely. I don't find Token reuse with DTLS possible to do securely..... am I missing something? Token reuse for TLS without Observer and without Groups communication seems quite easy. Do we need to say something about Group communication? Do we need to say something about stateless tokens? I think the current requirements on integrity protection and replay protection protection in the stateless draft should be enough.
I think John refers to e49ff36
Taken care of in the version -07
Change:
not decrypt the second ClientHello's ClientECH.payload value, if there is one. <del> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified integration with the backend server.  Stateful HRR on the client- facing server works fine, however.  See issue https://github.com/tlswg/draft-ietf-tls-esni/issues/333.]] </del> <ins> Note that a client-facing server that forwards the first ClientHello cannot include its own "cookie" extension if the backend server sends a HelloRetryRequest.  This means that the client-facing server either needs to maintain state for such a connection or it needs to coordinate with the backend server to include any information it requires to process the second ClientHello. </ins> 7.2.

Discussion:
URL don't give both servers a cookie. That is, if a client-facing server forwards the ClientHello, it can't do so statelessly without coordinating with the backend. This is a consequence of moving to a single HelloRetryRequest, but it's a minor one. In most cases, there will be state established anyway just to get the connection forwarded. DTLS might not work that way, but it's still likely reasonable to assume state. No longer builds on .
I guess the dust is still settling on the rest of the HRR mess, but a6b6b67ca710d023962b8b950a2d26f2806d7aac LGTM.
+1 -- NAME can we cherry-pick a6b6b67 into a separate PR?
I would be happy for you to take that and merge it.
Or, I will just rebase -i here.
I was thinking about and the discussion on server HRR checks started by URL, and I'm not sure HRR cookies even work in split mode right now. First off, suppose we don't merge something like . The current text says: This means if you get a cookied HRR only good for ClientHelloInner, there's no requirement to stick the cookie in ClientHelloOuter! But now the client-facing server can't see the cookie, so it can't be stateless. It would seem like fixes this, but now we have a more fundamental problem: whose cookie? Suppose the client-facing server wishes to handle HRR statelessly. It decrypts the first ClientHelloInner and forwards it to the backend server. If the backend server responds with HRR, the client-facing server must forward the HRR as-is, or the transcript breaks. But the client-facing server has no opportunity to bind its state (echhrrkey) into the HRR cookie. (Perhaps there isn't even one. If there is, it's encrypted with the backend server's key anyway. Either way, it's fixed now.) The simplest solution to all this is to only support stateful client-facing servers in split mode, unless the client-facing and backend servers can coordinate enough to share one cookie. I don't know if that would satisfy everyone. I could imagine doing something horrific to URL, akin to what we did to URL, but that sounds really messy.
Let's mark this as an "OPEN ISSUE" in the draft.
Done. URL
Change:
Signaling messages are introduced to allow peers to: <del> Share characteristics such as maximum message size for the </del> <ins> Related characteristics such as maximum message size for the </ins> connection <del> Shutdown the connection in an ordered fashion </del> <ins> Shut down the connection in an orderly fashion </ins> <del> Terminate the connection in response to a serious error condition </del> <ins> Provide diagnostic information when terminating a connection in response to a serious error condition </ins> Signaling is a third basic kind of message in CoAP, after requests and responses.  Signaling messages share a common structure with the

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
5.4. This document establishes a registry for HTTP capsule type codes. <del> The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type. This registry initially contains the following entry: </del> <ins> The "HTTP Capsule Types" registry governs a 62-bit space, and operates under the QUIC registration policy documented in QUIC.  This new registry includes the common set of fields listed in QUIC.  In addition to those common fields, all registrations in this registry MUST include a "Capsule Type" field which contains a short name or label for the capsule type. Permanent registrations in this registry are assigned using the Specification Required policy (IANA-POLICY), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections IANA- POLICY and IANA-POLICY of IANA-POLICY. </ins> Capsule types with a value of the form 41 * N + 23 for integer values of N are reserved to exercise the requirement that unknown capsule types be ignored.  These capsules have no semantics and can carry arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. <ins> This registry initially contains the following entry: </ins>

Discussion:
Seeing support and hearing no pushback, merging this as today marks the end of WGLC
When the first IANA registry was added to this document, it used "First Come First Served" to save time. This got carried over through the various changes and now the new "Capsule Type" registry is still marked that way. But in that corresponding time, the QUIC WG came up with a very good IANA policy for varint registries and documented it in RFC 9000. We should adopt that policy for Capsule Types.
I would like to note that changes like this is not editorial, it is something that should have consensus call.
Hi Magnus, I agree that this issue is not editorial. That's why I brought it up on this list over a week ago in its own thread (). This received two approvals on and no other comments or concerns. Hi MASQUE enthusiasts, While going over draft-ietf-masque-h3-datagram with Lucas to address some WGLC comments, we realized that the document introduced a new IANA 62bit registry for Capsule Types, with a "First Come First Served" registration policy. That was an oversight that was added a long time ago, and we'd like to switch it to using the same policy as the QUIC and HTTP/3 registries. If anyone objects to this change, please let us know on the GitHub issue: URL Thanks, David
Change:
Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be <del> enqueued separately.  To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete.  This can also help context switches when enqueuing data in the interface driver if the operation can be batched. </del> <ins> enqueued separately.  To avoid this, the application can indicate a batch of Send actions through the API.  When this is used, the implementation should hold off on processing Messages until the batch is complete. </ins> 5.2.

Discussion:
In the implementation draft section 5.1.3 says that there should be an interface for the application to indicate batch sending. Section 7.7 specifies such an interface. Should the section in the implementation draft be updated or removed?
I think it should be removed. Mainly, it points out that batching reduces overhead, which is also stated in the API draft in section 7.7.
Perhaps it is still important for the implementation to know that it needs to support batching sends though? I would suggest adjusting the text so it reads from the implementations perspective. Something like
I agree; this is a nice text proposal. PR replaces the current text with your proposed one.
Change:
Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. <ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In initial offers, this means those "m=" sections which do not contain an "a=bundle-only" attribute. "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the offer MUST be "actpass". An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. [TODO: rtcp-fb?] </ins> Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
A link has the following attributes: <del> One or more link relations (expressed as space-separated values in the "rel" attribute, defaulting to "hosts").  They describe a </del> <ins> Zero or more link relations (expressed as space-separated values in the "rel" attribute, defaulting to "hosts").  They describe a </ins> relations between the link context and the link target. A link context URI ("anchor").  The link context defines the source of the relation, and serves as the Base URI for resolving <del> the target.  It can be relative, in which case it gets resolved against the Base URI of the ".well-known/core" document it was obtained from . It can be absent, in which the Base URI of the document is used as the context. </del> <ins> the target.  In the serialization, it can be relative, in which case it gets resolved against the Base URI of the ".well-known/ core" document it was obtained from . It can be absent, in which the Base URI of the document is used as the context. </ins> A link target URI ("href", expressed between the angular brackets in link-format).  The link target defines the destination of the <del> relation, and is the topic of all other target attributes.  If it is a relative URI, it gets resolved against the link context URI. </del> <ins> relation, and is the topic of all other target attributes.  In the serialization, if it is a relative URI, it gets resolved against the link context URI. </ins> Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information

Discussion:
This is the first step to closing [54], doing the changes to the model itself. Won't close the issue by itself probably, as some other portions might mention the model. This does not try to address any of the open issues. [54]: URL
s taget/target/