jiebi/CodeConvo huggingface dataset:
Change:
Services implementation MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols.  A Transport Services implementation MAY allow <del> applications to explicitly specify that fallback to a specific other version of a protocol , e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. </del> <ins> applications to explicitly specify which versions of a protocol ought to be permitted, e.g., to allow a minimum version of TLS 1.2 in case TLS 1.3 is not available. </ins> 3.4.

Discussion:
We specifically left normative language for the security stuff.
From Watson Ladd: One minor nit in particular concerns the example of TLS fallback. It's not the case that one needs to carry out a fallback to TLS 1.2 if TLS 1.3 is available, and indeed that shouldn't be done. Ordinary TLS version negotiation should work just fine. A deeper nit concerns the way security is supposed to work in this system. It's true that e.g. both TLS and IKEv2 can use X509 certificates. It is not the case they use them the same way as they aren't authenticating the same thing. It is very much not the case that X509 validation involving trust verfication callbacks by the application works correctly, even conceptually or in most libraries, and the WebPKI will have very different additional requirements than other PKIs. It gets even more complicated when we consider how origin authority actually works in the web. I'm confused by the warnings on cross-protocol use of key material. For a PSK one really does want to link it to the protocol, but the same isn't true for X509 certificates across TLS and QUIC: you're supposed to use the same ones. I'm not sure how effective handling this all over to the application will be, or how the API will effectively make clear what connection the material will be used with in a racing environment.
These -arch sections contain normative language… didn't we try to get rid of all normative language in -arch?
Change:
that requested the creation of the session. Upon receiving an extended CONNECT request with a ":protocol" field <del> set to "webtransport", the HTTP server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4,RFC7231).  If it does, it MAY accept the session by replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del> <ins> set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  To accept a WebTransport session the server replies with 2xx status code.  Before accepting a session, a server MUST ensure that it authorizes use of the session by the site identified in the "Origin" header. </ins> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's

Discussion:
The resource does. It's a fine distinction, but an important one.
An excellent distinction, thank you :)
Change:
SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]] <del> Lastly, while the exact media parameters are only known only after a </del> <ins> Lastly, while the exact media parameters are only known only after an </ins> offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API Server to exchange secrets which can be used to validate future interactions. <del> The API must ensure the integrity of this information, as well as its </del> <ins> The API MUST ensure the integrity of this information, as well as its </ins> confidentiality. 7.4.

Discussion:
Does this also need to update the boilerplate text that defines SHOULD, MUST, etc?
forgot to mention that, but the draft is already updated to use 8174 boilerplate
In the paragraph starting at line 633, we say: In particular, " Consequently, any solution using the IP address should proactively" and "the components of the architecture must remove or update their" I think we should either capitalize these two or rephrase them.
Aside from my one comment, lgtm. I don't think the intention of the issue was to rephrase everything that used lowercase, but to make sure that we capitalized everything we needed to.
changed the 2 to capital case
lgtm, thanks.
A scrub for these to determine which are really requirements is a good idea. Also, update SS1.1 to use RFC 8174 boilerplate.
looks OK to me
Change:
ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the <del> Preconnection (i.e.  peer to peer establishment; rendezvous). </del> <ins> Preconnection (i.e., peer to peer establishment; rendezvous). </ins> Once a Connection is established, data can be sent and received on it in the form of Messages.  The interface supports the preservation of

Discussion:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good
Change:
checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to <del> the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this deadlock can happen.  To avoid the </del> <ins> the third party a deadlock can occur.  The use of OCSP RFC6960 servers or AIA for CRL fetching (RFC5280 Section 4.2.2.1) are examples of how this deadlock can happen.  To mitigate the </ins> possibility of deadlock, DNS API servers SHOULD bundle the certificate status as part of the handshake using a mechanism <del> appropriate to the version of TLS, such as using RFC6961 for TLS version 1.2. </del> <ins> appropriate to the version of TLS, such as using RFC6066 Section 8 for TLS version 1.2. </ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.

Discussion:
Please don't include advice about TLS extensions that aren't deployed. RFC 6961 is not widely implemented or used. I'm sad to say, but RFC 6066 is the best reference for OCSP stapling right now. Also, if you are including this sort of advice, advice against using AIA should go there as well. Some browsers chase AIA URLs in certificates, which will fail for similar reasons. (You can cite Section 4.2.2.1 of RFC 5280 for that bit).
NAME Given that this has wandered around a bit, could you create a PR with exactly the changes to the Operational Considerations that you think are needed here?
Change:
Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm. <del> Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. </del> <ins> Load balancers SHOULD drop short header packets with non-compliant DCIDs. </ins> The routing of long headers with non-compliant DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However,

Discussion:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Change:
The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in <del> the elements of the "challenges" dictionary.  For example, if the client wishes to complete the "simpleHttp" challenge, it needs to provide the "path" component.  (This is also the stage where the client should perform any actions required by the challenge.) </del> <ins> the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type,

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
4.2. <del> The pseudo-method CONNECT (RFC7231, Section 4.3.6) is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.  In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel to a remote host.  In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes. </del> <ins> The pseudo-method CONNECT (Section 4.3.6 of RFC7231) is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.  In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel to a remote host.  In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes. </ins> A CONNECT request in HTTP/3 functions in the same manner as in <del> HTTP/2.  The request MUST be formatted as described in HTTP2, Section 8.3.  A CONNECT request that does not conform to these restrictions is malformed (see malformed).  The request stream MUST NOT be closed at the end of the request. </del> <ins> HTTP/2.  The request MUST be formatted as described in Section 8.3 of HTTP2.  A CONNECT request that does not conform to these restrictions is malformed (see malformed).  The request stream MUST NOT be closed at the end of the request. </ins> A proxy that supports CONNECT establishes a TCP connection (RFC0793) to the server identified in the ":authority" pseudo-header field. Once this connection is successfully established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as <del> defined in RFC7231, Section 4.3.6. </del> <ins> defined in Section 4.3.6 of RFC7231. </ins> All DATA frames on the stream correspond to data sent or received on the TCP connection.  Any DATA frame sent by the client is transmitted

Discussion:
Martin flagged this on some imported text in , but others have crept in other places, mostly also as text imported from RFC7540. For future reference, (({{])), (Section d+(.d+)*) => 1
Change:
buffering incoming messages that might be associated with a handle that the receiver has not yet obtained. <ins> More generally, in order to prevent an appraising entity from generating false negatives (e.g., discarding Evidence that is deemed stale even if it is not), the appraising entity should keep an "epoch window" consisting of the most recently received handles.  The depth of such epoch window is directly proportional to the maximum network propagation delay between the first to receive the handle and the last to receive the handle, and it is inversely proportional to the epoch duration. The appraising entity shall compare the handle carried in the received Evidence or Attestation Result with the handles in its epoch window to find a suitable match. </ins> Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or

Discussion:
The handle-related portion of the Freshness section should provide some guidance on the extent of the "epoch window", i.e., the number of previously received handles that need to be kept by an appraiser to deal with propagation delay.
Change:
the removed leaf using the information in the Remove message Update the ratchet tree by setting to blank all nodes in the <del> direct path from the removed leaf to the root </del> <ins> direct path of the removed leaf </ins> The update secret resulting from this change is the secret for the root node of the ratchet tree after the second step (after the third

Discussion:
The very first commit from PR (6ba86ff561484a9eb96012e3b55b49f23cb8f9e9) was removed and a separate Issue is filled for unifying the use of "`" and "_".
We inconsistently use the backtick, the underscore or nothing for messages fields or specific operations in the draft. This needs a fix, currently the opinion is to use the TLS style (aka remove everything)
Change:
4.2. <del> Short headers take the form described in fig-short.  Bits that have version-specific semantics are marked with an X. </del> <ins> Short headers take the form described in fig-short. </ins> A QUIC packet with a short header has the high bit of the first byte set to 0.

Discussion:
Happened to notice that the updated figure (didn't check the old one) was inconsistent with the text about the allowed length of the CID fields. Should be editorial, since the text wins any conflicts.
Bah, yes, 255 bytes = 2,040 bits.
:D That's exactly the process that my mind followed.
Both section 4.2 and 4.3 say Unfortunately, the doesn't have Xs. I'm not sure how to reword this to support both formats.
how about :)
I think this was fixed by URL, I dont know if that was just a coincidence or it was untagged
That was intentional. I just neglected to tag this.
Change:
KeyPackage and Welcome messages are used to initiate a group or introduce new members, so they are exchanged between group members <del> and clients not yet in the group. </del> <ins> and clients not yet in the group.  A client publishes a KeyPackage via the DS, thus enabling other clients to add it to groups.  When a group member wants to add a new member to a group it uses the new member's KeyPackage to add the new member to the group and construct a Welcome message with which the new member can initialize its local state. </ins> Proposal and Commit messages are sent from one member of a group to the others.  MLS provides a common framing layer for sending messages

Discussion:
This removes the following graf: The DS and AS may also apply additional policies to MLS operations to obtain additional security properties. For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations. MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted. MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. My sense is this belongs in Security Considerations, not here.
This looks good to me. Please do move the removed paragraph to the security considerations, either here or in .
Change:
end-to-end encrypted. As such, two layers of encryptions and authentication are required: <del> 1- Hop-by-hop (HBH) encryption of media, metadata, and feedback messages between the the endpoints and SFU 2- End-to-end (E2E) encryption of media between the endpoints </del> <ins> Hop-by-hop (HBH) encryption of media, metadata, and feedback messages between the the endpoints and SFU End-to-end (E2E) encryption of media between the endpoints </ins> While DTLS-SRTP can be used as an efficient HBH mechanism, it is inherently point-to-point and therefore not suitable for a SFU

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
Require support for ECDSA, PFS, and AEAD <del> 11.2. </del> <ins> 11.3. </ins> Update cipher suite profiles. Rework IdP interaction based on implementation experience in Firefox. <del> 11.3. </del> <ins> 11.4. </ins> Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG

Discussion:
NAME I looked at the deletion issue and I don't think it's worth leaving it in as an exception, because you'd have to DTLS re-handshake anyway.
Change:
In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values.  The authentication, key <del> agreement, and record protection algorithms are determined by the </del> <ins> exchange, and record protection algorithms are determined by the </ins> cipher_suite selected by the server and revealed in the ServerHello message.  The random values are exchanged in the hello messages.  All that remains is to calculate the key schedule.

Discussion:
NAME please confirm this matches consensus
Now that we are removing static RSA cipher suites, we need a new MTI cipher suite.
From Sean's mail o Symmetric: MUST AES-GCM 128 [SHOULD ChaCha20-Poly1305] o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 [SHOULD 25519] o Signature: MUST ECDSA P-256 MUST RSA
Dear Mr. NAME currently I'm very interested in studying non-repudiation, then I found S-HTTP (RFC 2660) that offer non-repudiation security service. I also found that AS2 (RFC 4130) also offers this kind of service, but then I wonder why non-repudiation service is not becoming ubiquotus? Why AEAD replace HMAC, does hash function is too heavy, or hash is more appropriate for digital signature world? Thanks
Change:
scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an <del> entity called a Resource Directory (RD), which hosts registrations of resources held on other servers, allowing lookups to be performed for those resources. </del> <ins> entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </ins> This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, <del> maintain, lookup and remove resource descriptions.  Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.  Although the examples in this document show the use of </del> <ins> maintain, lookup and remove information on resources.  Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.  Although the examples in this document show the use of </ins> these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230.

Discussion:
I remember keeping web-links where it was beneficial to the text IMO OK with suggested change Peter chrysn schreef op 2018-11-09 16:43: Links: [1] URL [2] URL [3] URL
I'm fine with "Web Links" not being that prominent in the architecture any more; however, two mentions have survived in the three paragraphs above fig-arch, was that intentional?
Change:
This only takes effect when the transport uses a network layer that supports this functionality.  When it does take effect, setting this property to true will cause the sender to avoid network-layer source <del> frgementation.  When using IPv4, this will result in the Don't </del> <ins> fragmentation.  When using IPv4, this will result in the Don't </ins> Fragment bit being set in the IP header. Attempts to send a message with this property that result in a size

Discussion:
This seems otherwise inconsistent: for the noFragmentation property, we say that, in case of IPv4, setting this will result in setting the "Don't Fragment" bit. the noSegmentation property is described as avoiding fragmentation AND avoiding segmentation. So logically, this should also result in setting the "Don't Fragment" bit in case of IPv4. Generally, I'm not sure how an implementer should interpret the "can" here, in contrast with the "will" in the "Don't Fragment" case above... the textual difference seems to hint that this could be implemented differently, but then, how?
Change:
2.6. The following diagram shows the communication between each component <del> in the case where the Captive Network has a User Portal, and the User </del> <ins> in the case where the Captive Portal has a User Portal, and the User </ins> Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server.

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.