jiebi/CodeConvo huggingface dataset:
Change:
3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del> <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to

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:
Abstract <del> This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. </del> <ins> This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. </ins> <del> A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. </del> <ins> A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. </ins> 1.

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. <del> ICE agents MUST NOT use a Ta value smaller than 5 ms. </del> If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE

Discussion:
Annex B.1 also contain some text regarding the rate. E.g. "The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media starts flowing." I guess we should discuss whether: 1) We need to remove/modify that text 2) Whether B.1 is the place where we should talk about the global rate limit.
I'll own this issue because I'm driving discussion on the list around the transport guys' proposal for "MaxPackets+HTO+pacing".
Hopefully fixed by URL
Change:
HTTP GET requests to the collect job's URI with HTTP status code 200 OK and a body consisting of a "CollectResp": <del> The "encrypted_agg_shares" field is the vector of encrypted aggregate shares.  They MUST appear in the same order as the aggregator endpoints list of the task parameters. </del> <ins> "report_count" is the number of reports included in the aggregation. "encrypted_agg_shares" is the vector of encrypted aggregate shares.  They MUST appear in the same order as the aggregator endpoints list of the task parameters. </ins> If obtaining aggregate shares fails, then the leader responds to subsequent HTTP GET requests to the collect job URI with an HTTP

Discussion:
This adds a field to collect responses with the number of reports that contributed to the aggregation. Collectors will likely want this count to aid in the interpretation of aggregate results. (see ) There is also a change in draft-irtf-cfrg-vdaf-02 that opens the door for VDAFs that would require the report count during unsharding. (see cfrg/draft-irtf-cfrg-vdaf) Note that while this field is not part of the adjacent s, it will be protected by to the confidentiality of HTTPS and the leader-collector bearer token authentication.
I'm open to pushing it into the ciphertext, but my thinking was that a tampered reportcount would only affect robustness, not privacy, and thus we only need to arrive at the correct reportcount when all aggregators follow the protocol.
NAME can you please rebase? Sorry!
Collectors will want to know how many inputs are included in the aggregations they receive, for a number of reasons: they may wish to compute a mean over a privately aggregated sum, or track metrics on how many clients are providing inputs. struct should include a count of how many contributions went into an aggregation.
The linked PR only added a to the structure, which communicates it to the helper. I'm reopening this issue because the collector does not yet receive this information. In addition to the statistics-related motivation above, a recent PR to the VDAF spec, cfrg/draft-irtf-cfrg-vdaf, expects the number of reports to be available when unsharding.
This was completed in .
OK, seems reasonable to me.
Change:
Error negotiating version <del> permanent (if this document is approved) </del> <ins> provisional </ins> This document <ins> When this document is approved, it will request permanent allocation of a codepoint in the 0-63 range to replace the provisional codepoint described above. </ins>

Discussion:
I just saw a provisional registration for the 0xff73db value (from the current draft). This contains a note suggesting that the value might become permanent. Given how crucial version negotiation could be, I think we should seriously consider taking a codepoint from the 0-63 range.
Agreed, that was the intent but it wasn't clear from the draft. I wrote in to make it clearer.
Change:
provide keying material for the outer (hop-by-hop) algorithm is to use I-D.ietf-perc-dtls-tunnel. <ins> 3.1. In order to allow the inner and outer keys to be managed independently via the master key, the transforms defined in this document MUST be used with the following PRF, which preserves the separation between the two halves of the key: Here represents the default SRTP PRF RFC3711, represents the first half of the key, and represents the second half of the key. </ins> 4. The Original Header Block (OHB) contains the original values of any

Discussion:
Right now, the SRTP KDF destroys the separation between the inner and outer halves of the master key, which means that EKT can't set the E2E key without also resetting the HBH key. This PR moves from the default SRTP KDF to use a "split PRF" that preserves the separation between the E2E and HBH halves of the key.
LGTM
Change:
Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: <del> IP Version of A MUST be lesser or equal than IP Version of B </del> <ins> IP Version of A MUST be less than or equal than IP Version of B </ins> If the IP Version of A and B are equal, the IP Protocol of A MUST <del> be lesser or equal than IP Protocol of B. </del> <ins> be less than or equal than IP Protocol of B. </ins> If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly less than the Start IP

Discussion:
Where the word "lesser" is used, I think "less than" would read better. Especially in the construct "lesser or equal than"
SGTM
Change:
form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the <del> overall ICE process is considered to have failed. </del> <ins> overall ICE process typically is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote

Discussion:
It's a lot of words, makes the sentence harder to read, and given that this is introductory text, doesn't really clarify the document. I also think we'd have to similarly rewrite several other paragraphs in the intro if we did this, so I'm not in favor of adding the suggested text.
Perhaps, there are a few places that talks about "all pairs", without clarifying that it is for a checklist. So, at the moment, one could read the Introduction saying that ICE failure is typically declared once all pairs associated with the whole session have failed, which is not true. I assume you agree with that? As you have indicated yourself, ICE failure can be declared when all pairs associated with ONE checklist have failed, even if there are other checklists in the Completed state. Anyway, I think my issue is clarified in the "Update to RFC8445" section, so in order to move the draft forward, I am willing to accept ( ) and then leave the Introduction text as it is. I guess one has to assume that the reader of the draft knows ICE well enough to understand when ICE failure etc takes place.
Right, this is non-normative text, so I think we can keep it simple here and be specific (as we already have done) in the 8445 update section.
Change:
dispose of pooled tickets after some reasonable amount of time that mimics the ticket rotation period. <ins> Servers that do not enforce a limit on the number of NewSessionTicket messages sent in response to a "ticket_request" extension could leave themselves open to DoS attacks, especially if ticket creation is expensive. </ins> 6. The authors would like to thank David Benjamin, Eric Rescorla, Nick <del> Sullivan, Martin Thomson, and other members of the TLS Working Group for discussions on earlier versions of this draft. </del> <ins> Sullivan, Martin Thomson, Hubert Kario, and other members of the TLS Working Group for discussions on earlier versions of this draft. </ins>

Discussion:
If they don't enforce a limit, clients can cause them to do a lot of work.
Fixed by .
Approved pending
Change:
When a client discovers Designated Resolvers, it learns information such as the supported protocols and ports.  This information is <del> provided in Service Binding (SVCB) records for DNS Servers.  The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by I-D.ietf-add-svcb-dns. </del> <ins> provided in ServiceMode Service Binding (SVCB) records for DNS Servers, although AliasMode SVCB records can be used to direct clients to the needed ServiceMode SVCB record per I-D.ietf-dnsop- svcb-https.  The formatting of these records, including the DNS- unique parameters such as "dohpath", are defined by I-D.ietf-add- svcb-dns. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net":

Discussion:
Addressing
We should be explicit about AliasMode DDR records and give an example of where they are used. We should also mention the additional client complexity here, and we may wish to require that the unencrypted resolver include both the AliasMode and ServiceMode records in its response (with the latter in the additional section). A common use-case here will be if a network operator is using a managed service to provide a designated resolver service. In these cases it may be preferable to have URL be an AliasMode record to a ServiceMode record managed by the manage service operator.
One small nit, to avoid quasi normative language (may/MAY -> can).
Change:
3.5. <del> The ECDH ephemeral public keys are formatted as a COSE_Key of type EC2 or OKP according to Sections 7.1 and 7.2 of I-D.ietf-cose- rfc8152bis-algs, but only the 'x' parameter is included G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation as per RFC6090 MAY be used also in the COSE_Key.  If the COSE implementation requires an 'y' parameter, any of the possible values of the y-coordinate can be used, see Appendix C of RFC6090.  COSE always use compact output for Elliptic Curve Keys of type EC2. </del> <ins> EDHOC always uses compact representation of elliptic curve points, see comrep.  In COSE compact representation is achieved by formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and 7.2 of I-D.ietf-cose-rfc8152bis-algs, but only including the 'x' parameter in G_X and G_Y.  For Elliptic Curve Keys of type EC2, compact representation MAY be used also in the COSE_Key.  If the COSE implementation requires an 'y' parameter, the value y = false SHALL be used.  COSE always use compact output for Elliptic Curve Keys of type EC2. </ins> 3.6.

Discussion:
This was suggested in CFRG during the discussion on HPKE Elliptic-Curve-Point-to-Octet-String Conversion. The compact representation used in EDHOC can be used whenever compact output is used in ECDH (which it almost always is). Important to differenctiate between the wire format, the validation done, and the algorithm for multiplication. EDHOC only touch the wire format, and do not loosen any validation requirements or recommend any particular algorithms form multiplication. Suggestion oflline that it might be better to specify that the "y-bit" is set to 0 instead of giving the implementor an option. Suggestion offline that the draft should refer to SECG in addition or instead of NIST.
I made a PR trying to capture the suggestion from CFRG. I think the PR is ready to merge.
on page 14 would it not be suitable to add that IDCREDx = { x5chain : certificate in DER }, for x = I or R,
Very timely comment. I just made an update to this effect, see b5346fb. I didn't want to include this kind of notation as it requires explanation. Is it good enough?
Suggest to give it a bullet as well. Göran Selander schreef op 2021-02-22 11:26: Links: [1] URL [2] URL [3] URL
Change:
QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new <del> Connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected Connection ID. </del> <ins> connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected connection ID. </ins> This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load <del> balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such </del> <ins> balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Server Retry packet such </ins> that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB.

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
Public Key: The public key used by the Issuer for issuing and verifying tokens. <del> We assume that all protocol messages are encoded into raw byte format before being sent across the wire. </del> <ins> Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3. </ins> 3.

Discussion:
This is probably just a nitpick but I don't understand what you're assuming here. If the messages are encoded as raw byte format, isn't that really what the document is all about? Maybe what you want to be saying is more like whats in the ?
Change:
cancelling a request it has already begun processing. Implementations SHOULD cancel requests by abruptly terminating any <del> directions of a stream that are still open.  This means resetting the sending parts of streams and aborting reading on receiving parts of streams; see Section 2.4 of QUIC-TRANSPORT. </del> <ins> directions of a stream that are still open.  To do so, an implementation resets the sending parts of streams and aborts reading on the receiving parts of streams; see Section 2.4 of QUIC-TRANSPORT. </ins> When the server cancels a request without performing any application processing, the request is considered "rejected".  The server SHOULD

Discussion:
This PR covers questions asked during Auth48 which aren't pure copyediting, but seem to have a straightforward single-location fix. Individual commits, so it's easy to pull one out if someone disagrees.
In , the RFC Editor asks:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .
Change:
4.1.3. The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is <del> the output of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  For the purpose of using EDHOC- Exporter, an application only needs to store PRK_out or PRK_exporter. (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </del> <ins> the output session key of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  For the purpose of using EDHOC-Exporter, an application only needs to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2.

Discussion:
Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.
Change:
An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its response to the victim machine, thus <del> flooding it.  Depending on the selected ciphersuite this response </del> <ins> flooding it.  Depending on the selected parameters this response </ins> message can be quite large, as it is the case for a Certificate message.

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
2.2.1. <del> We refer to the DNS Update message sent by servers using SRP as an SRP Update.  Three types of updates appear in an SRP update: Service Discovery records, Service Description records, and Host Description records. </del> <ins> We refer to a DNS Update message that is constructed so as to conform to the constraints described in server_behavior as an SRP update. SRP Updates are sent by SRP requestors to SRP registrars.  Three types of updates appear in an SRP update: Service Discovery records, Service Description records, and Host Description records. </ins> RFC6763 describes the details of what each of these types of updates contains, with the exception of the KEY RR, which is defined in

Discussion:
I had a brief chat with Qiaoyu and the change here is the result of that discussion, including a minor editorial fix that makes a compound sentence a little more comprehensible (I hope).
Change:
3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by <del> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  That parameter is only defined for HTTP/2.  This document does not create a new multi- purpose parameter to indicate support for extended CONNECT in HTTP/3; instead, the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an endpoint supports extended CONNECT. </del> <ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL setting.  That setting is defined for HTTP/3 by RFC9220.  An endpoint supporting WebTransport over HTTP/3 MUST send both the SETTINGS_ENABLE_WEBTRANSPORT setting and the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with values set to "1". </ins> 3.3.

Discussion:
currently states: That is not well-defined: it relies on which only discusses HTTP/2, and the relevant changes between HTTP/2 and HTTP/3 are subtle. Since we have that is now in the RFC Editor Queue, WebTransport needs to instead refer to that and require servers to send .
This sounds like an obvious way forward. That said, I would personally prefer to wait until we make another breaking wire protocol change.
Sounds good to me, there's no rush here - in my personal opinion we just need to get this in before WGLC
More generally, it looks like we may want to remove any implied support and just require endpoints to explicitly signal support for each "layer" of capabilities that we're relying on.
Discussed at IETF 115, consensus in room to require all the relevant settings and transport parameters to be sent individually - for this issue means: require that SETTINGSENABLECONNECT_PROTOCOL be sent