jiebi/CodeConvo huggingface dataset:
Change:
or compromised devices from getting access to the network and potentially harming others. <del> Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for </del> <ins> Typically, solutions start with a specific component (called a "root of trust") that provides device identity and protected storage for </ins> measurements.  The system components perform a series of measurements <del> that may be signed by the Root of Trust, considered as Evidence about </del> <ins> that may be signed by the root of trust, considered as Evidence about </ins> the hardware, firmware, BIOS, software, etc. that is running. A device desiring access to a network

Discussion:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?
Change:
Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.5.1. </del> <ins> 3.6.1. </ins> Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to <del> "new_session_ticket" and to add the "hello_retry_request", "encrypted_extensions", "end_of_early_data", "key_update", and "message_hash" values. </del> <ins> "new_session_ticket" and to add the "hello_retry_request_RESERVED", "encrypted_extensions", "end_of_early_data", "key_update", and "message_hash" values. </ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.

Discussion:
I tend to narrow things from the right....
Programmer habits maybe, for me a "FooTest" is a specialization of "Test", so the current "KeyShareServerHello" looks like a specialization of "ServerHello" to me. It's a minor thing though.
Fair enough, but my habit is the opposite. :)
The text refers to helloretryrequest (e.g. in IANA considerations), but the HandshakeType enum refers to helloretryrequestRESERVED. Should something be said about Server Hello being able to modify ? Should something be said about rejecting handshake messages with ? (The current seems to suggest that the wire can really contain 6.)
My syntax validator also detects this error. We need to fix this.
I guess that it is hard to express a nested . So, it seems to me that a comment is reasonable:
That comment is not easy to parse for a machine :/ (btw, the comment is for the serverhello case, not clienthello). is only defined for enumerations, so we cannot do something like: (and even the above is not accurate since interpretation of random depends on the supportedextensions value.) Maybe something like: with the intention that ServerHelloParameters is populated while preparsing the SH message (prescan for supportedversions, detect HRR vs normal SH based on Random). This is inspired by the SecurityParameters type in RFC 5246.
LGTM. As a nitpick, maybe name it "ServerHelloKeyShare" instead of "KeyShareServerHello" (likewise for CH and HRR).
Change:
3.1. The following usage examples illustrate how an application might use <del> a Transport Services Interface to: </del> <ins> the Transport Services Interface to: </ins> Act as a server, by listening for incoming connections, receiving requests, and sending responses, see server-example.

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:
Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique <del> set of ICE candidates.  Bundle-only m= sections MUST NOT have any ICE credentials and MUST NOT gather any candidates. </del> <ins> set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </ins> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they

Discussion:
First cut. Need to update the examples.
Overall LG, a handful of comments
LGTM
lgtm and merged. Will do a new PR to handle minor tweaks
BUNDLE draft 27 (URL) indicates that ICE attributes and candidates in re-offers (and with max-bundle, I'm guessing) should only be in the "m=" line associated with the offerer BUNDLE-tag. In other words, the candidates and ICE parameters are not duplicated unnecessarily across m= sections. We should update JSEP to reflect this.
Change:
the server for information about its account (e.g., to examine the "contact" or "certificates" fields), then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS <del> whose payload is trivial ({"resource":"reg"}). </del> <ins> whose payload is trivial ({"resource":"reg"}).  In this case the server reply MUST contain the same link headers sent for a new registration, to allow a client to retreive the "new-authorization" and "terms-of-service" URI </ins> 6.3.1.

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
might already have retried unprocessed requests on another connection.  A server that is attempting to gracefully shut down a connection SHOULD send an initial GOAWAY frame with the last Stream <del> ID set to the current value of QUIC's MAX_STREAM_ID and SHOULD NOT increase the MAX_STREAM_ID thereafter.  This signals to the client that a shutdown is imminent and that initiating further requests is prohibited.  After allowing time for any in-flight requests (at least one round-trip time), the server MAY send another GOAWAY frame with an updated last Stream ID.  This ensures that a connection can be cleanly shut down without losing requests. </del> <ins> ID set to the maximum value allowed by QUIC's MAX_STREAMS and SHOULD NOT increase the MAX_STREAMS limit thereafter.  This signals to the client that a shutdown is imminent and that initiating further requests is prohibited.  After allowing time for any in-flight requests (at least one round-trip time), the server MAY send another GOAWAY frame with an updated last Stream ID.  This ensures that a connection can be cleanly shut down without losing requests. </ins> Once all accepted requests have been processed, the server can permit the connection to become idle, or MAY initiate an immediate closure

Discussion:
TBH I'm not sure the whole "set GOAWAY last stream id to MAXSTREAMID / maximum value allowed by MAX_STREAMS" is really necessary, but I kept it for now.
Change:
A rollback discards any proposed changes to the session, returning the state machine to the stable state, and setting the pending local <del> and/or remote description back to null.  Any resources or candidates </del> <ins> and/or remote description (see sec.pendinglocaldescription and sec.pendingremotedescription) to null.  Any resources or candidates </ins> that were allocated by the abandoned local description are discarded; any media that is received will be processed according to the previous local and remote descriptions.  Rollback can only be used to

Discussion:
Is there any other action to be taken for the issues mentioned in ?
NAME I concluded no.
Grouping these as one bug. Section 4.1.7.1 - the term "inactive" final answer is introduced without a defintion. Need to either define "inactive" or use another term. Section 4.1.7.2 Rollback - "and possibly the answerer as well" is wishy-washy. Suggest "and the answerer if it has done set-remote-description". Section 4.1.7.2 This is the first mention of "pending local / remote description". Suggest link to definition. Section 4.1.7.2 "RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed". The term "removed" is undefined. Deleted, discarded, destroyed or detached from the PeerConnection? Suggestion: "stopped and removed from the PeerConnection". (if the JS app still has a reference to them, it may still inspect the object).
LG % nit
Change:
contains an object of the following form, with the values used to identify the key and nonce: <del> When decoding an PrivateContentTBE, the application MUST check that </del> <ins> When decoding a PrivateContentTBE, the application MUST check that </ins> the FramedContentAuthData is valid. It is up to the application to decide what "authenticated_data" to

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:
The message size restrictions defined in Section 4.6 of CoAP RFC7252 to avoid IP fragmentation are not necessary when CoAP is used over a reliable byte stream transport.  While this suggests that the Block- <del> wise transfer protocol I-D.ietf-core-block is also no longer needed, it remains applicable for a number of cases: </del> <ins> wise transfer protocol RFC7959 is also no longer needed, it remains applicable for a number of cases: </ins> large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used

Discussion:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.
Change:
Supported transmitter tuning range with min/max nominal carrier frequency [f_tx_min, f_tx_max] <del> Supported transmitter tunability grid, the distance between two adjacent carrier frequencies (in GHz) </del> <ins> Supported transmitter tunability describing the transmitter's frequency fine tuning steps (the minimum distance between two adjacent carrier frequencies in GHz) </ins> Supported transmitter power range [p_tx-min, p_tx_max] Supported receiver channel power range [p_rx-min, p_rx_max] Supported maximum total power, rx power for all channels fed into

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass
Change:
When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens <del> until the AEAD keys have been replaced.  The easiest way to </del> <ins> until the traffic keys have been replaced.  The easiest way to </ins> accomplish this is to implement the Token as a counter, this approach SHOULD be followed.

Discussion:
"AEAD keys" -> "traffic keys" In (D)TLS, the algorithms may be other types than AEAD. "thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request." Some more text about this in the intro, the current text was very barebone.
Change:
necessary in systems that are non-windows-based but that have good notifications support, such as phones.] <del> Browsers MUST not permit permanent screen or application sharing </del> <ins> Browsers MUST NOT permit permanent screen or application sharing </ins> permissions to be installed as a response to a JS request for permissions.  Instead, they must require some other user action such as a permissions setting or an application install experience

Discussion:
There were two instances of "MUST not" that need to be "MUST NOT"
Address I-D nits complaints.
Change:
It contains multiple Add proposals that contain KeyPackages that represent the same client according to the application (for <del> example, identical KeyPackages or KeyPackages sharing the same Credential). </del> <ins> example, identical signature keys). It contains an Add proposal with a KeyPackage that represents a client already in the group according to the application, unless there is a Remove proposal in the list removing the matching client from the group. </ins> It contains multiple PreSharedKey proposals that reference the same PreSharedKeyID.

Discussion:
In , it was pointed out that we previously had a clause: But this was amplified in to say that we also can't send Add proposals for users that are already in the group. I think we should talk about if this is the actual desired behavior or not.
I agree with Brendan. Specifically I want to make sure an MLS client can replace itself. My other concern is that because we have no guidance yet on identity, we need to make sure that multiple instances/clients of the same user are allowed.
Interim 2022-05-26: We want to: Avoid having multiple appearances of the same device Allow a device to resync itself Text at issue here is "An Add proposal is invalid if ... The Credential in the KeyPackage represents a client already in the group according to the application" It sounds like changing to "... The KeyPackage represents a client already in the group according to the application" would address the immediate concern NAME to write a PR
Change:
13. <ins> changes from -14 to -15 Talk of "relative references" and "URIs" rather than "relative" and "absolute" URIs.  (The concept of "absolute URIs" of RFC3986 is not needed in RD). </ins> changes from -13 to -14 Rename "registration context" to "registration base URI" (and

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
are application specific, mainly depending on the latency requirements and message frequency of the application.  In this case, the application mapping must specify whether the client or server is <del> responsible for keeping the application alive.  Note that sending PING frames more frequently than every 30 seconds over long idle periods may result in a too much unproductive traffic and power usage for some situations. </del> <ins> responsible for keeping the application alive.  While Hatonen10 suggests that 30 seconds might be a suitable value for the public Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to lower network and computational load.  Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices. Additionally, time-outs shorter than 30 seconds can make it harder to handle trasient network interruptions, such as VM migration or coverage loss during mobilty. </ins> Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a

Discussion:
"Idle period", "network idle timeout", and "idle timeout" are distinct; addresses a comment in .
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by
Change:
exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724. <ins> If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. </ins> 3.4. The primary mechanism to deal with middle boxes is ICE, which is an

Discussion:
o Added a SHOULD NOT about using deprecated temporary IPv6 addresses. o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657
Some systems keep old IPv6 addresses around even when changing to new for privacy. How should we avoid trying the ones that don't make sense to try?
As documented here: URL and here: URL it appears that the implementers claim everything is working as designed on systems which accumulate several temporary deprecated IPv6 addresses. My assumption here is that using deprecated temp addresses as ICE candidates (additionally to the non deprecated temporary address) is not going to increase the likeliness of establishing a connection. So adding these additional ICE candidates only causes extra over head. Therefore adding a warning/clarification statement for implementers to avoid deprecated temporary IPv6 addresses (in case there is usable non-deprecated temporary IPv6 address available) seem appropriate.
Adding warning in -12: "If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses."
Sounds good to me.
Addressed in (version -12)
Change:
11.1. This document creates a new registration for the identification of <del> HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol </del> <ins> HTTP/3 in the "Application-Layer Protocol Negotiation (ALPN) Protocol </ins> IDs" registry established in RFC7301. The "h3" string identifies HTTP/3:

Discussion:
as well as other instances of the term. RFC 7301 does indeed hyphenate (and that's correct, since "application-layer" is being used as a single unit to describe "protocol").
URL says the registry is
Change:
In order to ensure that clients do not encapsulate messages that other entities can intercept, the key configuration MUST be <del> authenticated and have integrity protection.  One way to ensure integrity for key configuration is for the oblivious request resource to serve content to the client directly, using HTTPS and the "application/ohttp-keys" media type; see ohttp-keys. </del> <ins> authenticated and have integrity protection. This document describes the "application/ohttp-keys" media type; see ohttp-keys.  This media type might be used, for example with HTTPS, as part of a system for configuring or discovering key configurations.  Note however that such a system needs to consider the potential for key configuration to be used to compromise client privacy; see privacy. </ins> Specifying a format for expressing the information a client needs to construct an encapsulated request ensures that different client

Discussion:
The whole mess that is key configuration discovery needs real work. There are cases where trust suffices, but we can't rely on that here. What this does is tweak the language to more clearly note the lines of responsibility for this draft. I also noted that we didn't talk about trial decryption and tracking, so I added that. It seemed like we didn't need to mention multiple keys with the same identifier twice after that.