jiebi/CodeConvo huggingface dataset:
Change:
STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified. <ins> Within each m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather- overview), an "a=candidate" line MUST be added, as specified in RFC5245, Section 4.3., paragraph 3.  If candidate gathering for the section has completed, an "a=end-of-candidates" attribute MUST be added, as described in I-D.ietf-mmusic-trickle-ice, Section 9.3. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </del> <ins> The default ICE candidate policy MUST be set to "all" as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-

Discussion:
LGTM
lgtm
From URL "public" is probably something the browser should control, not the application. "none" was previously removed, but apparently Firefox has implemented it.
Keep in mind that anything less than all means that mobile apps will work better than browser apps. Public tries to just reveal what is already revealed simply by browsing the web with no webrtc.
Right, but that's what "all" does when the browser is configured as recommended by draft-rtcweb-shieh-ip-handling. It's not clear why a "public" mode also needs to exist; the point of this draft is to protect the user from the application, so we can't really give the app the ability to choose whether it wants non-public addresses. I think the real remaining question is whether "none" is worth keeping.
I think the motivation for "none" was a lot stronger when we had automatic gathering prior to setLD() in some situations. Now, it seems like you can just get the same effect by deferring setLD(). I agree that "public" is silly.
Change:
WireGuard <ins> OpenVPN </ins> 4.2.1. Of the protocols listed above that depend on the transport for

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:
value of specific Claims if it knew that only certain values were accepted by the Relying Party. <del> Conceptual messages carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections. </del> <ins> Conceptual messages (see messages) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Discussion:
Signed-off-by: Dave Thaler
** Section 12.2 Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or appraisal policy ... Should reference values be included?
same changes, conceptual messages
Change:
A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other <del> Unencrypted DNS Resolver.  Instead, the client SHOULD repeat the </del> <ins> Unencrypted DNS Resolver.  Instead, the client needs to repeat the </ins> discovery process to discover the Designated Resolver of the other Unencrypted DNS Resolver.  In other words, designations are per- resolver and MUST NOT be used to configure the client's universal DNS

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
The <del> is a sequence of "passings" the basic model's edges, where </del> <ins> is a sequence of "passings" of the basic model's edges, starting at a node identifying the document (its retrieval context, typically URI from which it was obtained) where </ins> each edge is passed at least one time in total, each edge is passed at most one time after each passing that ends in its start point (with the obvious exception that edges from the <del> root node can be passed once from the start), and </del> <ins> retrieval context can be passed once from the start), and </ins> between a passing of an edge from A to B and a later passing from B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. <del> The passings starts at the root node, usually defined as the URI from which the document is obtained. </del> For better understanding, think of the structured information model <del> as a sort of tree spanning from the root node, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. </del> <ins> as a sort of tree spanning from the retrieval context, with the oddity that when a node is reached along two different edges (which a normal tree doesn't do), it is up to the builder of the tree whether to describe anything children of the entered node on one parent or on the other parent, on both, or to describe some children at the first and others at a later occasion. </ins> 1.1.2.

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:
If the path through which the message was received is not preferred, a "return_routability_check" message of type <del> "path_delete" MUST be returned.  In either case, the peer </del> <ins> "path_drop" MUST be returned.  In either case, the peer </ins> endpoint echoes the cookie value in the response. The initiator receives and verifies that the

Discussion:
Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop
Change:
The client MUST send a Certificate message whenever the server has requested client authentication via a CertificateRequest message <del> (certificate-request) or when the EarlyDataIndication indicates client authentication.  This message is only sent if the server requests a certificate.  If no suitable certificate is available, </del> <ins> (certificate-request) or when the EarlyDataType provided with the server configuration indicates a need for client authentication. This message is only sent if the server requests a certificate via one of these mechanisms.  If no suitable certificate is available, </ins> the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).

Discussion:
This cleans up some of the text around EarlyDataIndication that was introduced previously.
The early data indication parameters are defined as clientauthentication(1), earlydata(2), and clientauthenticationanddata(3). A few paragraph after that, some text refers to them by what was probably an old name: If TLS client authentication is being used, then either "earlyhandshake" or "earlyhandshakeand_data" MUST be indicated in order to send the client authentication data on the first flight. Easy fix...
See URL
This should now be fixed.
Change:
case of server authentication), this field SHALL be zero length. This is a sequence (chain) of CertificateEntry structures, each <del> containing a single certificate and set of extensions.  The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> containing a single certificate and set of extensions. </ins> A set of extension values for the CertificateEntry.  The "Extension" format is defined in extensions.  Valid extensions

Discussion:
Explicitly define RFC 7250 certificate support.
Seems reasonable. (I did not try to audit the rest of the text to see if there are other places that need updating.)
This captures what we talked about in Chicago.
Shucks, this hasn't landed yet, so I'll have to remember to update my editorial changes pull request that puts the numbers for these into the enumerated type definition for extensions.
Change:
6.3.1. <del> Content to be encrypted is encoded in an PrivateContentTBE structure. </del> <ins> Content to be encrypted is encoded in a PrivateContentTBE structure. </ins> The "padding" field is set by the sender, by first encoding the content (via the "select") and the "auth" field, then appending the

Discussion:
URL
:+1: Thank you very much for all of the explicitly worked examples. What is the reason for MUST vs RECOMMENDED difference in the two different circumstances when validating the `lifetime` field? Consider adding a platitude about communicating nodes SHOULD use some method of time synchronization... "top of these basic mechanism" -> "top of these basic mechanisms" (or maybe "top of this basic mechanism") "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"
Change:
10.4.1. <del> An endpoint detects a potential stateless reset when a packet with a short header either cannot be decrypted or is marked as a duplicate packet.  The endpoint then compares the last 16 bytes of the packet with the Stateless Reset Token provided by its peer, either in a </del> <ins> An endpoint detects a potential stateless reset when a incoming packet with a short header either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet. The endpoint then compares the last 16 bytes of the packet with the Stateless Reset Token provided by its peer, either in a </ins> NEW_CONNECTION_ID frame or the server's transport parameters.  If these values are identical, the endpoint MUST enter the draining period and not send any further packets on this connection.  If the

Discussion:
If connection for incoming packet cannot be found, check whether this is a stateless reset packet.
states: This only works for endpoints whose SCID is zero length. If SCID is not zero length, the connection corresponding to the stateless reset packet will not be found. This latter case should be included in the stateless reset detection algorithm.
OK with the requested changes.
Change:
if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of <del> type "TRANSPORT_PARAMETER_ERROR". </del> <ins> type TRANSPORT_PARAMETER_ERROR. </ins> If the Version Information was missing, the endpoints MAY complete the handshake if they have reason to believe the peer might not

Discussion:
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
Change:
QUIC can use the session resumption feature of TLS 1.3.  It does this by carrying NewSessionTicket messages in CRYPTO frames after the <del> handshake is complete.  Session resumption is the basis of 0-RTT, but can be used without also enabling 0-RTT. </del> <ins> handshake is complete.  Session resumption can be used to provide 0-RTT, and can also be used when 0-RTT is disabled. </ins> Endpoints that use session resumption might need to remember some information about the current connection when creating a resumed

Discussion:
Resumption is not quite the basis of 0-RTT, since it is also allowed to pre-provision an external PSK and other parameters and do 0-RTT that way. This also allows a rewording to avoid implying that 0-RTT would need to be enabled by configuration, since it is supposed to just be "on by default".
NAME said:
Having just reviewed all instances of 0-RTT, I'm not seeing anything that I disagree with in terms of tone and posture. Most of the language does treat 0-RTT as a normal part of the protocol, though it is very careful to highlight the risks. I think that is entirely appropriate. Short of being provided with specific problems or recommendations, I propose no action here.
How do you feel about s/Session resumption is the basis of 0-RTT, but can be used without also enabling 0-RTT./Session resumption can be used to enable 0-RTT, and can also be used when 0-RTT is disabled./ (recalling that we had another change to clarify that 0-RTT can be used independently of resumption, if sufficient information is configured alongside the external PSK)? To clarify, the concern here is that if 0-RTT is something that you "enable", then there would be some precursor state where 0-RTT is disabled by default. Disabled by default may not mesh very well with "normal part of the protocol". Thank you for reviewing the other instances; I only happened to notice this one place in Section 4.5 but was not specifically looking for others.
It's a fine point, but I wouldn't object to making that change in line with other 0-RTT changes. I think that the chances of ever seeing non-resumption 0-RTT are so remote as to be irrelevant, but we can still be accurate.
Change:
The string "tls-sni-01" <del> A serialized authorized key object, base64-encoded.  The "key" field in this object MUST match the client's account key. </del> <ins> A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> Number of tls-sni-01 iterations <del> In response to the challenge, the client MUST decode and parse the authorized keys object and verify that it contains exactly one entry, whose "token" and "key" attributes match the token for this challenge and the client's account key.  The client then computes the SHA-256 digest Z0 of the JSON-encoded authorized key object (without base64-encoding), and encodes Z0 in UTF-8 lower-case hexadecimal form.  The client then generates iterated hash values Z1...Z(n-1) as follows: </del> <ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client first computes the SHA-256 digest Z0 of the UTF8-encoded key authorization, and encodes Z0 in UTF-8 lower-case hexadecimal form.  The client then generates iterated hash values Z1...Z(n-1) as follows: </ins> The client generates a self-signed certificate for each iteration of Zi with a single subjectAlternativeName extension dNSName that is

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
the external init secret as described in external-initialization. The sender type for the MLSPlaintext encapsulating the External <del> Commit MUST be "new_member" </del> <ins> Commit MUST be "new_member_commit" </ins> External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's

Discussion:
Add new newproposalmember SenderType and rename newmember to newcommit_member. This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.
Interim 2022-06-02: Could punt to extensions, but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved, good to merge
LGTM, though would still prefer etc. One minor suggestion to lock down the content.
Change:
1.3. <del> When [RFC8829] was published, an inconsistency regarding BUNDLE RFC8843 operation was identified concerning both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by RFC8829.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate the use of "max-bundle" and instead introduce a new "must- bundle" policy that, when selected, provides the correct behavior. </del> <ins> When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843 operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </ins> 2.

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:
doesn't get notified when network access is restricted.  Hence, end- user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. <ins> 7.6. ue_identity describes a mechanism by which all components within the Captive Portal are designed to use the same identifier to uniquely identify the User Equipment.  This identifier could be abused to track the user.  Implementers and designers of Captive Portals should take care to ensure that identifiers, if stored, are stored securely. Likewise, if any component communicates the identifier over the network, it should ensure the confidentiality of the identifier on the wire by using encryption such as TLS. There are benfits to choosing mutable anonymous identifiers.  For example, User Equipment could cycle through multiple identifiers to help prevent long-term tracking.  However, if the components of the network use an internal mapping to map the identity to a stable, long-term value in order to deal with changing identifiers, they need to treat that value as sensitive information: an attacker could use it to tie traffic back to the originating User Equipment, despite the User Equipment having changed identifiers. </ins>

Discussion:
This adds a privacy section which discusses the implications of the User Equipment identity. I'm open to suggestions for more content here. Some thoughts: State that may not contain the identity, but can be mapped to from it? Logging?
Benjamin writes, We need a bit more text here.