jiebi/CodeConvo huggingface dataset:
Change:
set of protocols and algorithms that are requested by applications or by a system policy. <ins> The protocols surveyed in this document represent a superset of functionality and features a Transport Services system may need to support.  It does not list all transport protocols that a Transport Services system may need to implement, nor does it mandate that a Transport Service system implement any particular protocol. A Transport Services system may implement any secure transport protocol that provides the described features.  In doing so, it may need to expose an interface to the application to configure these features. </ins> 2. The following terms are used throughout this document to describe the

Discussion:
Do you think this non-goal is helpful for people who are confused that "important" security protocols are omitted from this survey? (e.g. )
This document is a survey of network security protocols and their interaction with transport and application protocols. It is clearly written and easy to read. I have a minor comment on the contents of this draft. It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft. Some notable omissions include SSH, L2TP, and GRE. These seem like interesting omissions given their popularity in a number of deployment scenarios. Not a showstopper in my opinion, but interesting to note.
Proposal: Add a paragraph to non-goals saying that we are not attempting to provide a comprehensive survey of all security protocols, or a survey of all "important" protocols that a TAPS implementation would have to support. Perhaps this also isn't entirely clear in the Introduction, which says our included protocols represent "a superset of features a Transport Services system may need to support". By this, we mean that it may need to implement any protocol that provides these features, and/or it may need to expose an interface to configure these features. We do NOT mean that the Transport Services System has to implement these exact protocols, or that it should limit itself to these protocols. But people might be misunderstanding it this way.
I think this is a fine idea -- thanks for the PR!
Change:
protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. <ins> Note that this document only clarifies requirements of name server software implementations.  It does not place any requirements on data placed in DNS zones or registries. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
For issue .
A colleague asked me to clarify that the document applies only to name server behavior, and does not place any requirements on how zones or registries are populated. i.e., we are not saying that "glue is not optional" for delegations in a zone.
This was done with commit 45cb8efcbf03c193791a14894aeb8d9d2a15096e
Change:
end user encounters certificates with vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate. However, if those certificates were not governed by the KeyPurposeIds <del> owner but by another vendor, the vender who own the KeyPurposeIds may </del> <ins> owner but by another vendor, the vendor who own the KeyPurposeIds may </ins> not able to control use, or even do not know about the use. - If the issuance of the cert is not under the control of the KeyPurposeIds owner, it is hard to estimate the impact of change to made on the

Discussion:
Addressing Lars' .
Debating adding more context than just "document". Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw). Did you mean "documents" here instead of "Internet-Drafts"? All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. File types are normally capitalized. A period is needed after the abbreviation "etc.".
Change:
it wishes to share with the user (e.g., store info, maps, flight status, or entertainment). <del> "expire-date" (optional, string formatted as RFC3339 datetime): indicates the date and time after which the client will be in a </del> <ins> "seconds-remaining" (optional, integer): indicates the number of seconds remaining, after which the client will be placed into a </ins> captive state.  The API server SHOULD include this value if the client is not captive (i.e. captive=false) and SHOULD omit this value for captive clients.

Discussion:
Completes
As discussed in the IETF hackathon/informal meeting, the consensus is to change expire-date (an absolute iso datetime) to seconds-remaining integer (named after bytes-remaining)
This was already done!
thanks, missed that
The draft currently specifies a deadline as an absolute time. Experience with implementation showed that time remaining (in seconds) was easier to implement and less subject to the vagaries of clock differences.
Change:
4. <ins> This protocol allows future extensions to exchange HTTP Datagrams which carry different semantics from UDP payloads.  Some of these extensions can augment UDP payloads with additional data, while others can exchange data that is completely separate from UDP payloads.  In order to accomplish this, all HTTP Datagrams associated with UDP Proxying request streams start with a context ID, see format. Context IDs are 62-bit integers (0 to 2 -1).  The context ID value of zero is reserved for UDP payloads, while non-zero values are dynamically allocated: non-zero even- numbered context IDs are client-initiated, and odd-numbered context IDs are server-initiated.  Extensions can use the next available context ID for their own purposes.  Note that, once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. Additionally, note that the context ID namespace is tied to a given HTTP request: it is possible for the same numeral context ID to be used simultaneously in distinct requests. 5. </ins> When associated with UDP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see HTTP-DGRAM) has the following format: <del> The design team meetings will continue until morale improves. </del> <ins> A variable-length integer that contains the value of the Context ID.  Endpoints MUST silently drop any received HTTP Datagram which carries an unknown Context ID. </ins> The payload of the datagram, whose semantics depend on value of the previous field.  Note that this field can be empty. <del> UDP packets are encoded using HTTP Datagrams with the To Be Determined field set to TBD0.  When the To Be Determined is set to TBD0, the Context Payload field contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). </del> <ins> UDP packets are encoded using HTTP Datagrams with the Context ID set to zero.  When the Context ID is set to zero, the Context Payload field contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its UDP proxying request, noting however

Discussion:
This is one potential design for the identifier at the start of the CONNECT-UDP datagram payload. Note that this PR is against the design team consensus branch, not main. . .
During the HTTP Datagrams Design Team meeting on 2022-01-20, we reached consensus to move forward with the dynamic approach, so I'm merging this PR.
Change:
A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated <del> with, divided by four.  (The division by four stems from the fact </del> <ins> with, divided by four (the division by four stems from the fact </ins> that HTTP requests are sent on client-initiated bidirectional <del> streams, and those have stream IDs that are divisible by four.) </del> <ins> streams, and those have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 2 -1, so the largest legal value of Quarter Stream ID is 2 -1 / 4.  Receipt of a frame that includes a larger value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is

Discussion:
…king hte law Also, switch to format to beatuiful superscript HTML rendering as used by RFC 9000.
Stating the obvious here. But we're using value with a legal range larger than semantically legal. RFC 9000 has some similar caveats with MAX_STREAMS URL To address this, the suggestion is to add something like
That suggestion sounds good to me.
Change:
If the the above checks are successful, consider the updated GroupState object as the current state of the group. <del> The "finished_mac" value is computed over the provisional group state and the current handshake message (with the confirmation value set to zero): </del> <ins> The "signature" and "confirmation" values are computed over the transcript of group operations, using the transcript hash from the provisional GroupState object: </ins> HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. <ins> Sign uses the signature algorithm indicated by the signer's credential in the roster. </ins> [[ OPEN ISSUE: The Add and Remove operations create a "double-join" situation, where a participants leaf key is also known to another

Discussion:
Looking at the signature and confirmation calculations in the current draft and comparing them to TLS, things seemed a bit complicated. In TLS, we have the following: This PR implements an analogous computation for MLS, where the signature in a message covers the transcript hash in the latest group state (which includes any changes to the roster ~ Certificate), and the confirmation MAC covers the transcript hash, plus the signature (i.e., the contents of CertificateVerify).
Merging this despite CI failures because they seem to be spurious.
Change:
Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. <del> Verify that expected_version matches the protocol version indicated in the server's "supported_versions" extension. </del> Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements.

Discussion:
As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson
Change:
of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards). <del> 7.7. </del> <ins> 7.8. </ins> A sender becomes idle if it ceases to send data and has no bytes in flight.  A sender's congestion window MUST NOT increase while it is

Discussion:
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them. Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space. Replaces
merging this one as well to get this in -18.
A few comments, editorial.
Change:
When a participant A wants to establish a group with B and C, it first downloads InitKeys for B and C.  It then initializes a group <del> state containing only itself and uses the InitKeys to compute Add messages to add B and C, in a sequence chosen by A.  These messages are broadcasted to the Group, and processed in sequence by B and C. Messages received before a participant has joined the group are ignored.  Only after A has received its Add messages back from the server does it update its state to reflect their addition. </del> <ins> state containing only itself and uses the InitKeys to compute Welcome and Add messages to add B and C, in a sequence chosen by A.  The Welcome messages are sent directly to the new members (there is no need to send them to the group).  The Add messages are broadcasted to the Group, and processed in sequence by B and C.  Messages received before a participant has joined the group are ignored.  Only after A has received its Add messages back from the server does it update its state to reflect their addition. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download an InitKey for a new participant and

Discussion:
This PR addresses two outstanding issues with Welcome messages: Welcome messages were not encrypted for the new member, so that the information in them (in particular, init secrets) were not appropriately protected. The protocol overview had not been updated to include the Welcome-based add flow.
This was resolved in , but recording it in this issue for posterity. A Welcome message carries the value for the group, and so it needs to be encrypted for the new joiner. The struct proposed in the revised draft wraps the information in the Welcome in an ECIES ciphertext, and adds enough information to enable the joiner to identify the private key it needs to decrypt the Welcome message.
Change:
This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an <del> X509 certificate.  This proof can be exported by one peer, </del> <ins> X.509 certificate.  This proof can be exported by one peer, </ins> transmitted out-of-band to the other peer, and verified by the receiving peer.

Discussion:
got merged while I was reviewing it, so here's my feedback as a follow-up PR. I initially though line 244 needed a comma, but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity, so I dropped that one.
Thanks, Mike.
Change:
cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with <del> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for </del> <ins> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for </ins> CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748.

Discussion:
remove extra _ at the end of name -- the name in SignatureScheme enum lacks it
Change:
half. The client MUST ensure that the certificate is served to TLS <del> connections specifying a Server Name Indication (SNI) value of SAN B. </del> <ins> connections specifying a Server Name Indication (SNI) value of SAN A. </ins> The response to the TLS-SNI challenge simply acknowledges that the client is ready to fulfill this challenge.

Discussion:
This replaces tls-sni-01 with tls-sni-02, which requires that domains being validated return a certificate which contains a hostname that is not revealed by the server in its handshake. This ensures that challenges cannot be passed by domains which auto-generate self-signed certificates in response to requests with SANs for domains not previously seen.
Change:
calling an RS, all steps involving the RS below do not apply. In some circumstances, the information needed at a given stage is <del> communicated out-of-band or is pre-configured between the components </del> <ins> communicated out of band or is preconfigured between the components </ins> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.

Discussion:
iss-sub was renamed to iss_sub in draft -06 of secevent identifiers drop unnecessary hyphenation the initial introduction sentence still might need some more significant rewording
Change:
that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. <ins> While the Certificate message in TLS 1.3 is encrypted, third parties can draw inferences from the message length observed on the wire. TLS 1.3 provides a padding mechanism (discussed in Sections 5.4 and E.3 of RFC8446) to counteract such analysis.  Certificate compression alters the length of the Certificate message, and the change in length is dependent on the actual contents of the certificate.  Any padding scheme covering the Certificate message has to address compression within its design, or disable it altogether. </ins> 6. It's been observed that a significant number of middleboxes intercept

Discussion:
LGTM. NAME can you accept NAME suggestion? I can't do that myself as the branch is on a separate repo. Then it's ready to merge I think.
Change:
8.1. <ins> The application may check a property to determine if a received Message is the Final Message on a Connection.  For any Message that is marked as Final, the application can assume that there will be no more Messages received on the Connection once the Message has been completely delivered.  This corresponds to the Final property that may be marked on a sent Message send-final. Some transport protocols and peers may not support signaling of the Final property.  Applications therefore should not rely on receiving a Message marked Final to know that the other endpoint is done sending on a connection. Any calls to "Receive" once the Final Message has been delivered will result in errors. 8.2. </ins> The Receive Event is intended to be fired once per application-layer Message sent by the remote endpoint; i.e., it is a desired property of this interface that a Send at one end of a Connection maps to

Discussion:
Satisfies
Okay, addressed capitalization and took Brian's suggested paragraph (with one tiny change).
Fine with me - go ahead
NAME NAME any further comments on this one?
ship it
Sorry, seems I should have clicked "approve" earlier. Still being clumsy in github :(
Change:
The sixth-eighth least significant bits are reserved and SHALL be set to zero when not in use. <ins> The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). The following 1 byte encode the length of the Context Hint (context-hint) s, if the Context Hint flag is set (h = 1). The following s bytes encode the Context Hint, if the Context Hint flag is set (h = 1). </ins> The remaining bytes encode the value of the kid, if the kid is present (k = 1) <ins> Note that the kid MUST be the last field of the object-security value, even in case reserved bits are used and additional fields are added to it. </ins> The presence of Partial IV and kid in requests and responses is specified in cose-object, and summarized in fig-byte-flag. 8.2. <del> The payload of the OSCORE message SHALL be encoded as follows: The first n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). The following 1 byte encode the length of the Context Hint (context-hint), s, if the Context Hint flag is set (h = 1). The following s bytes encode the Context Hint, if the Context Hint flag is set (h = 1). The remaining bytes encode the ciphertext. </del> <ins> The payload of the OSCORE message SHALL encode the ciphertext. </ins> 8.3.

Discussion:
This implements the change I suggested in , ie move everything but the ciphertext from CoAP payload to the option value. The text about kid being the last field is a draft, please modify if you have any better formulation.
Change:
calculated by combining the packet protection IV with the packet number and with the path identifier. <del> The path ID for 1-RTT packets is the sequence number of of QUIC- </del> <ins> The path ID for 1-RTT packets is the sequence number of QUIC- </ins> TRANSPORT, or zero if the Connection ID is zero-length.  Section 19 of QUIC-TRANSPORT encodes the Connection ID Sequence Number as a variable-length integer, allowing values up to 2^62-1; in this

Discussion:
It's a grammar error fix in the aead section.
from URL The path ID for 1-RTT packets is the sequence number of of {{QUIC-TRANSPORT}} maybe it should be The path ID for 1-RTT packets is the sequence number of Connection ID of {{QUIC-TRANSPORT}}
Thanks Wu! I fixed this grammar error in PR .
Change:
malformed.  The recipient of such a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code. <ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: </ins> 4.2. The IP proxy SHALL indicate a successful response by replying with

Discussion:
Our cousin, CONNECT-UDP, has simple examples about how the requests and responses look in HTTP/1.1, 2 and 3. I appreciate the appendix has complicated examples. Would it be worth providing simple examples in Section 4, or at least forward referencing to them so people can get a feel?
That would be nice, if someone's willing to volunteer to do the editorial work of writing that PR. In other words, I'll happily review and merge it, but I don't have time to write it personally.
there's 5 authors on the draft, maybe one of the other 4 can spare the 10 minutes it would take?
Simple enough to add =)
Thanks for writing this!
Change:
a specific component for which it is a candidate. Each component has an ID assigned to it, called the component ID. <del> For RTP-based media data streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a component ID of 1, and RTCP a component ID of 2.  In case of RTP/RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP. </del> <ins> For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a component ID of 1, and RTCP a component ID of 2.  In case of RTP/RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP. </ins> When candidates are obtained, unless the agent knows for sure that RTP/RTCP multiplexing will be used (i.e. the agent knows that the

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”