jiebi/CodeConvo huggingface dataset:
Change:
routing of packets across multiple network paths will also allow activity on those paths to be linked by entities other than the peer. <del> A client might wish to reduce linkability by employing a new connection ID and source UDP port when sending traffic after a period of inactivity.  Changing the UDP port from which it sends packets at the same time might cause the packet to appear as a connection migration.  This ensures that the mechanisms that support migration are exercised even for clients that do not experience NAT rebindings or genuine migrations.  Changing port number can cause a peer to reset its congestion control state (see migration-cc), so the port SHOULD only be changed infrequently. </del> <ins> A client might wish to reduce linkability by switching to a new connection ID, source UDP port, or IP address (see RFC4941) when sending traffic after a period of inactivity.  Changing the address from which it sends packets at the same time might cause the server to detect a connection migration.  This ensures that the mechanisms that support migration are exercised even for clients that do not experience NAT rebindings or genuine migrations.  Changing address can cause a peer to reset its congestion control state (see migration-cc), so addresses SHOULD only be changed infrequently. </ins> An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts

Discussion:
... is good for linkability.
Éric Vyncke said:
I don't think that is appropriate in the general case. However, in , we say this: We could point to privacy addresses as an option here. That is not a bad idea as IPv6 clients can't rely on NAT to the same extent that IPv4 clients do.
Using "optionally" inside "might wish to" seems overly wishy-washy. How about "employing a new connection ID, source UDP port, and/or IP address (see {{?RFC4941}})...."?
Change:
querying for their presence and support.  Optional features may not be implemented, or may be disabled if their presence impacts transport services or if a necessary transport service or application <del> dependency is unavailable.  In this context, an application dependency is one required from an application in order to function. </del> <ins> dependency is unavailable. In this context, an application dependency is an aspect of the security feature which can be exposed to the application.  An application dependency may be required for the security feature to function, or it may provide additional information and control to the application.  For example, an application may need to provide information such as keying material or authentication credentials, or it may want to restrict which cryptographic algorithms to allow for negotiation. </ins> 5.1.

Discussion:
As promised at IETF 103, here's a suggested definition of application dependency, to make it clearer what I'm talking about. I have also added dependencies for the mandatory features, so that it's clear for all features whether they have any application dependencies. In addition, I changed the heading of the section because the section does not actually talk about transport dependencies anymore. What do you think?
Yep, I agree. This change looks good. Thank you, NAME good with these changes.
Change:
D.sandj-tls-iana-registry-updates has been applied.]] TLS ContentType Registry: Future values are allocated via <del> Standards Action RFC2434. </del> <ins> Standards Action RFC5226. </ins> TLS Alert Registry: Future values are allocated via Standards <del> Action RFC2434. </del> <ins> Action RFC5226. </ins> TLS HandshakeType Registry: Future values are allocated via <del> Standards Action RFC2434.  IANA [SHALL update/has updated] this </del> <ins> Standards Action RFC5226.  IANA [SHALL update/has updated] this </ins> registry to rename item 4 from "NewSessionTicket" to "new_session_ticket".

Discussion:
RFC 5226 obsoleted RFC 2434 so we should refer to that to avoid a GENART review comment.
Change:
All packets sent after receiving and processing transport parameters might be affected, including Initial, Handshake, and Retry packets. <del> A client MAY also clear the QUIC Bit in packets that are sent prior to receiving transport parameters from the server.  However, a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include a token provided by the server in a NEW_TOKEN frame (Section 19.7 of QUIC) received less than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter. </del> <ins> A client MAY also clear the QUIC Bit in Initial, Handshake, or 0-RTT packets that are sent prior to receiving transport parameters from the server.  However, a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include a token provided by the server in a NEW_TOKEN frame (Section 19.7 of QUIC), received less than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter. </ins> This 7 day limit allows for changes in server configuration.  If server configuration changes and a client does not set the QUIC

Discussion:
URL Has there been any analysis done for the 7 day rule? or is this just an agreed value. It would be nice to provide some reasoning behind the 7 day rule.
This matches the recommendations in TLS for session tickets, which prohibit the use of tickets after 7 days. But I don't think we should hide from the fact that this is completely and unapologetically arbitrary. Arbitrary is OK; justification only papers over that.
If this is completely arbitrary then we should not need to recommend this, this is not an experimental specification. In that case it makes sense to even drop it. But I see this is not really that much arbitrary, and reflects the practice for TLS session token. I think we can just say that. in this case we can go from SHOULD to MAY, making it optional. by the way I also think, the security consideration falls short on this topic. If we are recommending something then we it is better to say what happens when it is not followed.
It is arbitrary, but it does need a specified maximum. What happens when it is not followed is that packets can't be processed.
yes, if we say something then it will be best to specify a maximum. so the question now from my side is - do we need a strong recommendation (SHOULD) or can we make is optional (MAY)? if we don't have enough experience of actual deployment of it them perhaps it is best that we make it optional. But I am interested to hear why this should be a "SHOULD". when you say "packets can't be processed" do you mean at server? can we write this down?
The text already says why:
now that we have explicitly added handshake and 0-RTT packet in this clause, the to me call for a attention from the WG to review. Otherwise looks good to me. Latest text LGTMThanks for addressing my nits
Change:
response for the client.  The access token MUST be bound to the RPK of the client by means of the "cnf" claim. <del> The response MUST contain an "ace_profile" parameter if the"ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth- authz).  This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key. The authorization server MUST return in its response the parameter </del> <ins> The response MUST contain an "ace_profile" parameter if the "ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth-authz). This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key.  The authorization server MUST return in its response the parameter </ins> "rs_cnf" unless it is certain that the client already knows the public key of the resource server.  The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource

Discussion:
It is perhaps a stretch to call the description of using a for DLTS 1.3 as "editorial", but it really is the analogous way to do it, so this seems like just some additional exposition and not new content. I think that it will be okay to just include this in the XML file provided to the RFC Editor when they ask for one after approval.
Change:
Inputs: <del> "s_cfg": A "ServerConfig" struct. </del> <ins> "srv_cfg": A "ServerConfig" struct. </ins> <del> "message": A "ClientRedemptionMessage" struct. </del> <ins> "message": A "ClientRedemptionRequest" struct. </ins> Outputs:

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
correlate communications for a given user agent.  It MUST NOT be possible to correlate any two push resource URIs based solely on their contents.  This allows a user agent to control correlation <del> across different applications, or over time. </del> <ins> across different applications, or over time.  Of course, this does not prevent correlation using other information that a user agent might expose. </ins> Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation

Discussion:
This attempts to address all of the issues identified during AD review: URL I have reviewed this document in preparation for IETF last call. It is almost ready to go. I have a few comments below. Once these are resolved and a rev published, I will request publication. = Shepherd write-up = RFC 2818 is in the downref registry already. That is the only explanation necessary for the downref. = Section 5.3 = I'm assuming the application scenarios listed in the table are illustrative since they do not cover every possible application. It would be good to note that. = Section 5.4 = "Delivery receipts for the deleted message SHOULD be suppressed." Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. = Section 8 = I think the first paragraph should include a normative recommendation to follow the guidance in RFC 7525 for use of TLS. = Section 8.2 = I think it would be useful to acknowledge in this section that while correlation using push URIs can be limited in the various ways described, correlation based on other information exposed by user agents may still be possible. = Section 9.3 = The Contact should be IETF Chair (per RFC 6335).
Change:
The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated <del> transceiver. </del> <ins> transceiver.  Note that non-JSEP endpoints are not subject to these restrictions, and might offer media formats that were not present in the most recent answer, as specified in RFC3264, Section 8.  Therefore, JSEP endpoints MUST be prepared to receive such offers. </ins> The media formats on the m= line MUST be generated in the same order as in the current local description.

Discussion:
Fixes issue .
Note that I made this a MAY and not a MUST, because the only precedent for a MUST in codec selection is with regards to the mandatory codecs.
This seems like it still needs some more work, as we discussed earlier.
I added some more informative text about non-JSEP endpoints. Does this address your concerns Ekr? There are still some questions about when (if ever) a JSEP endpoint is allowed to include previously discarded codecs in an offer (issue ), but this PR should at least address issue .
Browser offer MCU, VP9, and VP10. MCU answers with VP10. Offer / answer completes. Later the MCU offers VP9 to browser on m-line that was currently use VP10. What does the browser do? A strict reading of spec might suggest that since MCU only offered VP9, and current is VP10, the m-line should be rejected. Do we need to change this ? Is it OK for browser to respond with VP9.
Previously I've heard people say "the non-JSEP endpoint can do whatever it wants with codecs." For example, in the thread for issue .
It is definitely OK for the browser to accept the VP9 in the updated offer and I would go further and say that it must accept VP9 in such an updated offer if it is capable of doing so. The spec should make it clear that browsers MUST accept such codec changes in updated offers.
If we solve this, should resolve.
Originally raised by Magnus. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. I think this is a bad advice. I think it should say that if this is the case, PT should not be used to try to determine which m= section it belongs to. I think wrongly attributing a packet is worse than dropping it in cases where the information is incomplete. This rule can result in that one associate an SSRC with the wrong m= section.
there is another bug on this too - I agree we could change this
Obsoleted by events - moved to BUNDLE
With changes above
Change:
The aggregator keeps track of the number of times each report was aggregated.  If any input share in "X" was added to at least "max_batch_lifetime" previous batches, then the aggregator aborts <del> and alerts the peer with error "privacyBudgetExceeded". </del> <ins> and alerts the peer with error "batchLifetimeExceeded". </ins> 4.7.

Discussion:
Adds definitions of error codes to section 3.1 for validation of batch intervals in or . Also adds an error code for leader to use when rejecting a report from too far in the future.
NAME I can't request review from you until you accept the invite to the ietf-wg-ppm organization but you should see this PR too!
Change:
party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use TLS or a protocol with comparable security properties as its <del> underlying transport to keep the certificate confidential.  The </del> <ins> underlying transport to keep the Certificate confidential.  The </ins> application MAY use the existing TLS connection to transport the authenticator. An authenticator message can be constructed by either the client or <del> the server given an established TLS connection, a certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the certificate_request_context is chosen by the server. </del> <ins> the server given an established TLS connection, an identity, such as an X509 certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the certificate_request_context is chosen by the server. </ins> 5.1.

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
8.4. A Remove message is sent by a group member to remove one or more <del> members from the group. </del> <ins> other members from the group.  A member MUST NOT use a Remove message to remove themselves from the group.  If a member of a group receives a Remove message where the removed index is equal to the signer index, the recipient MUST reject the message as malformed. </ins> The sender of a Remove message generates it as as follows:

Discussion:
This clears up the wording around how to prune the ratchet tree on a Remove operation. Previously, it could be interpreted as "remove nodes from the tree until the rightmost node is not null", but this is not what is intended by the authors, and it also has the ability to produce invalid trees (i.e., trees with an even number of elements). The second change is to do the truncation after doing the Blank propogation up the direct path of the removed leaf. Note that the order of these steps doesn't matter in that they produce the same resulting tree. However, if we blank after pruning, an implementor would have to take care to not to try to blank out previously-removed nodes. Prune-then-blank is a little easier to reason about. The third change is a semantic fix. It is clear from the last paragraph in this section that the root node should be blanked, but the text only said to blank the direct path of the leaf, which does not include the root node. I just added that part in.
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs.  Specifically, URIs learned via any of the options in option should take precedence <del> over any URI learned via a mechanism like the one described in linkrel. </del> <ins> over any URI learned via some other mechanism, such as a redirect. </ins> If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device owner or administrator.  URI precedence in this situation is not specified by this document. <del> 5. </del> <ins> 4. </ins> This document requests two new IETF URN protocol parameter (RFC3553) entries. Thanks IANA! <del> 5.1. </del> <ins> 4.1. </ins> <del> 5.1.1. </del> <ins> 4.1.1. </ins> Registry name: Captive Portal Unrestricted Identifier

Discussion:
At IETF 106, we discussed removing the link relation. This PR does that.
I suppose we should be reading and implementing draft-ietf-git-github-wg-configuration ... As Warren's T-shirt says: "In my defense I was left unsupervised."
100% agreed about the build output...
People who put build output in their repository deserve a special place.
Change:
multiple ciphersuites. The value for "init_key" MUST be a public key for the asymmetric <del> encryption scheme defined by cipher_suite, and it MUST be unique </del> <ins> encryption scheme defined by "cipher_suite", and it MUST be unique </ins> among the set of KeyPackages created by this client.  Likewise, the "leaf_node" field MUST be valid for the ciphersuite, including both <del> the "hpke_key" and "credential" fields.  The whole structure is </del> <ins> the "public_key" and "credential" fields.  The whole structure is </ins> signed using the client's signature key.  A KeyPackage object with an invalid signature field MUST be considered malformed.

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
Add a per-ticket nonce so that each ticket is associated with a different PSK (*). <ins> Clarify that clients should change to sending with handshake keys immediately upon reading ServerHello.  Arguably a wire format change. (*). Update state machine to show rekeying events </ins> Add discussion of 0-RTT and replay.  Recommend that implementations implement some anti-replay mechanism.

Discussion:
NAME NAME I would appreciate a sanity check here.
Maybe remove the "arguably" statement and the *
Change:
An implementation may support only a single method.  None of the methods are mandatory-to-implement. <ins> Implementations MUST support 'kid' parameters of type int.  None of the other COSE header parameters are mandatory-to-implement. An implementation may support only a single credential type (CCS, CWT, X.509, C509).  None of the credential types are mandatory-to- implement. </ins> Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate. <del> Implementaions MAY support message_4.  Error codes 1 and 2 MUST be </del> <ins> Implementations MAY support message_4.  Error codes 1 and 2 MUST be </ins> supported. <del> Implementations MUST support 'kid' parameters of type int. Editor's note: Is any COSE header parameters (kid, kcwt, kccs, x5t, c5c, etc. ) MTI? Editor's note: Is any credential type (CCS, CWT, X.509, C509) MTI? Editor's note: Is support of EAD MTI? </del> <ins> Implementations MAY support EAD. </ins> For many constrained IoT devices it is problematic to support more than one cipher suite.  Existing devices can be expected to support

Discussion:
Suggestion base the discussion during the October interim. There was no strong opinions. This PR updates the MTI for header parameters and credential types to align with the choices made for method (none is MTI). EAD is explicitly optional to support. It is used in specific cases and requires additional mechanics for each use case.
The things that are Mandatory or optional to support or now spread out in various places.
This does not need to be a new section (like the MTI section in TLS 1.3) but it definitly needs to be clear what in the draft is mandatory to implement or not. Could be as simple as stating. Everything is mandatory Nothing is mandatory Something in between Currently is is undefined which is not good I think
I started making an MTI section inspired by RFC 8446. I think this makes things clearer. I added some editorial notes in the section that needs to be discussed.
MTI section now in place and no editor's notes left.