jiebi/CodeConvo huggingface dataset:
Change:
4.2.1. <del> Transport Properties are referred to by property names.  These names are alphanumeric strings in which words may be separated by hyphens. These names serve two purposes: </del> <ins> Transport Properties are referred to by property names.  For the purposes of this document, these names are alphanumeric strings in which words may be separated by hyphens.  These names serve two purposes: </ins> Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a policy manager, or as a representation of properties retrieved from a file or other storage. <del> Making code of different TAPS implementations look similar. </del> <ins> Making code of different TAPS implementations look similar.  While individual programming languages may preclude strict adherence to the aforementioned naming convention (for instance, by prohibiting the use of hyphens in symbols), users interacting with multiple implementations will still benefit from the consistency resulting from the use of visually similar symbols. </ins> Transport Property Names are hierarchically organized in the form [<Namespace>.]<PropertyName>.

Discussion:
Updates PR to remove reference to lower-case in namespaces corresponding to IANA protocol names. Express that strict adherence to the doc's naming convention is not required, but that symbols in different languages should be visually similar.
NAME NAME Last minute PR
Change:
lines, as specified in RFC4566, Section 6, and RFC3264, Section 5.1. <del> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in RFC4566, Section 6.  This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </del> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.
Change:
that might arrive before the peer has packet protection keys to process those packets. <del> 6.6. </del> <ins> 6.7. </ins> Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST however count these packets as being additionally in

Discussion:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!
Change:
Address case nits <ins> Fix section bullets in 4.1.3. Add operational considerations section for clock skew </ins> Add text around using an oracle to forge DCs in the future and past

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
Time-Sensitive Network. <del> 3. </del> <ins> 2.3. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
Major clean up and simplification as data plane drafts can be referred for MPLS related details. TSN over DetNet MPLS follows the concept of RFC3985. Description focus on Edge Nodes procedures and functions. Text covers the Edge Nodes components: (1) TSN functions (in NSP block); (2) DetNet Service Proxy; and (3) DetNet sub-layers.
Approving from teelcon review
Change:
0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake, application_data, and alert respectively) but are protected under <del> different keys.  After all the 0-RTT application data messages (if any) have been sent, an "end_of_early_data" alert of type "warning" is sent to indicate the end of the flight.  0-RTT MUST always be followed by an "end_of_early_data" alert, which will be encrypted with the 0-RTT traffic keys. </del> <ins> different keys.  After receiving the server's Finished message, if the server has accepted early data, an "end_of_early_data" alert of type "warning" MUST be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </ins> A server which receives an "early_data" extension can behave in one of three ways:

Discussion:
The alert is described as being part of the first flight, but it is really sent when the server Finished is received, per the processing order section. Notably, servers MUST NOT wait for endofearlydata before sending ServerHello through Finished. Group it with the client Finished flight, and fix the text about it terminating the first flight. (The division between the first and second client flight isn't especially well-defined because early data may flow in parallel with the ServerHello flight. But if there is to be a division, endofearlydata certainly falls into the second one.)
Yes, this should help avoid one of the most common mistakes in 0-RTT implementations.
LGTM.
Change:
such implementations must still be able to send connection identifiers of different length to other parties. <ins> Note that it is not possible to parse the records without knowing how long the Connection ID is. </ins> In DTLS 1.2, connection ids are exchanged at the beginning of the DTLS session only.  There is no dedicated "connection id update" message that allows new connection ids to be established mid-session,

Discussion:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.
Change:
Deprecate SHA-1 with signatures. <ins> Add MTI algorithms. </ins> draft-08 Remove support for weak and lesser used named curves.

Discussion:
NAME please confirm this matches consensus
Now that we are removing static RSA cipher suites, we need a new MTI cipher suite.
From Sean's mail o Symmetric: MUST AES-GCM 128 [SHOULD ChaCha20-Poly1305] o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 [SHOULD 25519] o Signature: MUST ECDSA P-256 MUST RSA
Dear Mr. NAME currently I'm very interested in studying non-repudiation, then I found S-HTTP (RFC 2660) that offer non-repudiation security service. I also found that AS2 (RFC 4130) also offers this kind of service, but then I wonder why non-repudiation service is not becoming ubiquotus? Why AEAD replace HMAC, does hash function is too heavy, or hash is more appropriate for digital signature world? Thanks
Change:
Use the "confirmation_key" for the new epoch to compute the confirmation MAC for this message, as described below, and verify that it is the same as the "confirmation" field in the <del> GroupOperation object. </del> <ins> MLSPlaintext object. </ins> If the the above checks are successful, consider the updated GroupContext object as the current state of the group.

Discussion:
Here's the Weekly Digest for : This week, 8 issues were created. Of these, 4 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by The issue most discussed this week has been: :speaker: , by It received 9 comments. This week, no pull requests has been proposed by the users. This week, 4 users have contributed to this repository. They are , , , and . This week, no user has starred this repository. This week, there have been 4 commits in the repository. These are: :hammerandwrench: Merge pull request from rozbb/mlsplaintext-signature Multiple clarifications around Framing by :hammerandwrench: Merge pull request from rozbb/hpke-encrypt Clarify how HPKE ciphertexts are computed by :hammerandwrench: by :hammerand_wrench: by # RELEASES This week, no releases were published. That's all for this week, please watch :eyes: and star :star: to receive next weekly updates. :smiley:
Change:
acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying <del> packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. </del> <ins> packets based on packet size are likely to fail, and are not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </ins> 4.7.

Discussion:
The text says: “and are emphatically NOT RECOMMENDED.” I think I would agree with a strong encouragement to not do this, but I would suggest to not use upper case letters at this point, and I’m not sure “emphatically” is a great word in a RFC :-). I’d also note that the volume of ACK traffic really can be a problem that QUIC needs to address, because QUIC over radio (of various types) can be significantly more expensive or lower performant than TCP, precisely because the control/ACK traffic is much more and there is no opportunity for network mitigation - hence it behoves QUIC implementors to use appropriate methods.
I created an PR to address the first point. Regarding the second point: NAME do you want to propose additional text? However, if I think that would go the into applicability...?
Suggestion for text: On network paths where there is significant asymmetry, the transmission of QUIC ACKs can reduce the efficient use of network capacity or transmission opportunities. This effect occurs when the return capacity is significantly more constrained than the forward capacity, or the cost of transmission per packet is a significant component of the total transmission cost. Reducing the ratio of acknowledgements to data at the QUIC receiver can improve link utilization and reduce link transmission costs.
Change:
When the server can parse the client's first flight using the original version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that <del> the client thinks its first flight is compatible with. </del> <ins> the client knows its first flight is compatible with. </ins> If the server supports one of the client's compatible versions, and <del> the server also believes that the original version is compatible with </del> <ins> the server also knows that the original version is compatible with </ins> this version, then the server converts the client's first flight to that version and replies to the client as if it had received the converted first flight.  The version used by the server in its reply

Discussion:
This draft talks about clients and servers "thinking" and "believing" things. Those verbs don't necessarily apply to protocol implementations, no matter what new frontiers we're exploring in the machine learning space. Might be worth a pass to rephrase these in terms of client or server capabilities and information. "Know" is a little fuzzier, since an endpoint does in fact possess information at certain points in the process.
So... when my computer says "thinking ...", are you saying it's lying to me?
URL
Change:
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are <del> derived from PRK_out, see exporter.  An application using EDHOC- KeyUpdate needs to store PRK_out.  If EDHOC-KeyUpdate is not used, an application only needs to store PRK_out or PRK_exporter as long as EDHOC-Exporter is used.  (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> 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. <del> This section defines EDHOC-Exporter and EDHOC-KeyUpdate in terms of EDHOC-KDF and PRK_out. </del> <ins> This section defines EDHOC-Exporter in terms of EDHOC-KDF and PRK_out. </ins> 4.2.1.

Discussion:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.
Change:
Revealing the Stateless Reset Token allows any entity to terminate the connection, so a value can only be used once.  This method for choosing the Stateless Reset Token means that the combination of <del> connection ID and static key cannot occur for another connection.  A denial of service attack is possible if the same connection ID is </del> <ins> connection ID and static key MUST NOT be used for another connection. A denial of service attack is possible if the same connection ID is </ins> used by instances that share a static key, or if an attacker can cause a packet to be routed to an instance that has no state but the same static key (see reset-oracle).  A connection ID from a <del> connection that is reset by revealing the Stateless Reset Token cannot be reused for new connections at nodes that share a static key. </del> <ins> connection that is reset by revealing the Stateless Reset Token MUST NOT be reused for new connections at nodes that share a static key. </ins> Note that Stateless Reset packets do not have any cryptographic protection.

Discussion:
We don't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design, but there is no sense in sending long headers.
While I agree with the issue, the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway. I can see this, but given that, I think it is pointless to require the current version to only send resets for short headers. A general advice ought to suffice since the MUST is not enforceable anyway.
The requirement exists to protect those packets from detection.
Please don't close issues until AFTER consensus is declared (not just called).
I suspect Martin was confused because this issue was tagged has-proposal 15 days ago.
Right. The trigger is , not .
But it's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago, given this has been tagged with has-proposal for 15 days.
Change:
A parent node may also only have one child (or leaf) node, such as a when a hostname resolves to only a single IP address. <del> 4.1.2. </del> <ins> 4.1.3. </ins> There are three types of branching from a parent node into one or more child nodes.  Any parent node of the tree must only use one type of branching. <del> 4.1.2.1. </del> <ins> 4.1.3.1. </ins> If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the

Discussion:
Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment. Remove that previous section. was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment, but I haven't changed any of the text yet. I am a little concerned about creating an interdependancy in the text between derriving endpoints (name lookup) and the ICE/TURN stuff. More generally, I am not sure what to say about name resolution and proxies (ala ). TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address.
Looks good apart from typo!
Having proxies to go through on a system (SOCKS, HTTP Connect, etc) or a set of TOR endpoints requires the implementation to do some nested/recursive work, and pass down endpoints correctly to protocol instances. The implementation document should describe this.
+1
There is already text in 4.1.3.3. Protocol Options. Is that sufficient or do we need more?
Review structure. What fits in pre-establishment. Relation system policy - cached state. Generalizes
Discussed in Singapore, we'll have more structure comments later, but we've done a lot of changes since then.
I like the change, as it makes the process much clearer and reduces the awkwardness of ICE/STUN. To model TOR, SOCKS, or other tunnelling protocols, I would refrain from seeing them as protocol stacks, but treat them as derived paths that only support these stacks. This removes the need for cupeling name resolution to the protocol stack, and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing. If we want to do so, it might be easier to talk about paths (that have one or more corresponding local endpoints), derived paths, derived remote endpoints (as result of name resolution on each path) and protocol stacks.
Change:
redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME, Section 2.2), as shown in the figure below. <ins> The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used; see ISSUANCE for more information. </ins> Clients interact with the Attester and Issuer to produce a token in response to a challenge.  The context in which an Attester vouches for a Client during issuance is referred to as the attestation

Discussion:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.
Change:
challenge failed. Different challenges allow the server to obtain proof of different <del> aspects of control over an identifier.  In some challenges, like HTTP, TLS SNI, and DNS, the client directly proves its ability to do certain things related to the identifier.  The choice of which challenges to offer to a client under which circumstances is a matter of server policy. </del> <ins> aspects of control over an identifier.  In some challenges, like HTTP and DNS, the client directly proves its ability to do certain things related to the identifier.  The choice of which challenges to offer to a client under which circumstances is a matter of server policy. </ins> The identifier validation challenges described in this section all relate to validation of domain names.  If ACME is extended in the

Discussion:
Recent developments[[0]] [[1]] [[2]] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 and its currently specified replacement, TLS-SNI-02. In light of these issues and the feasibility of addressing them across the entire Internet it seems prudent that the ACME specification remove the affected challenge type pending the development of a better alternative (TLS-SNI-03?). This will allow the draft last-call to proceed while the details of TLS-SNI-03 are worked out. The "Default Virtual Hosts" sub-section of the "Operational Considerations" section is removed since it spoke exclusively to a concern with TLS-SNI-02 validation. When the dust has settled on TLS-SNI-03 we should certainly include a section that describes why TLS-SNI-01/02 were removed that could replace this information. [0]: URL [1]: URL [2]: URL
NAME I don't think we need a place-holder in-doc for this
r+ with the one comment addressedShould there be any mention of that makes sure we use in a future RFC in case if gets re-added?