jiebi/CodeConvo huggingface dataset:
Change:
A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody <del> Option in the corresponding Pong message.  The receiver SHOULD delay its Pong message until it finishes processing all the request/ response messages received prior to the Ping message on the current connection. </del> <ins> Option in the corresponding Pong message.  In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/response messages received prior to the Ping message on the current connection. </ins> 5.5.

Discussion:
URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.
Change:
similar to example-discovery. A Resource Directory may optionally support HTTP.  Here is an example <del> of the same registration operation above, when done using HTTP. </del> <ins> of almost the same registration operation above, when done using HTTP and the JSON Link Format. </ins> 5.3.1.

Discussion:
See individual commit messages
As we support the alternative serializations from draft-ietf-core-links-json, I'd like to add at least the numbers in the RD lookup examples.
Use TBD64 etc., as discussed in the call.
Change:
on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. <del> 5.2. </del> <ins> 6.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP

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:
2.2. The Deprecation header field applies to the resource identified with <del> the response it occurred within (see Section 3.1.4.1 of HTTP), meaning that it announces the upcoming deprecation of that specific resource.  However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears. </del> <ins> the response it occurred within (see HTTP), meaning that it announces the upcoming deprecation of that specific resource.  However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears. </ins> Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of

Discussion:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.
Change:
most cases can be used to infer the domain being visited Patil-2019. Port is useful for allowlisting certain applications. <ins> Combining IP address, port and protocol information found in the transport header, shallow packet inspection can be used by a censor to identify specific TCP or UDP endpoints.  UDP endpoint blocking has been observed in the context of QUIC blocking Elmenhorst-2021. </ins> Trade-offs: header identification is popular due to its simplicity, availability, and robustness.

Discussion:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.
Change:
probing. To avoid these types of situations, which can potentially affect all <del> the users whose streaming media segments traverse a bottleneck, there are several possible mitigations that streaming operators can use. However, the first step toward mitigating a problem is knowing that a problem is occurring. </del> <ins> the users whose streaming media segments traverse a bottleneck path segment, there are several possible mitigations that streaming operators can use.  However, the first step toward mitigating a problem is knowing that a problem is occurring. </ins> 3.2.1.

Discussion:
From NAME -
NAME - after thinking about this comment, I think two things need to happen - your observation about bottlenecks at different nodes/hops/layers of the protocol stack belongs at the beginning of this section, because we're drilling down on ONE layer of the protocol stack in the rest of section 3.2, and as you say, the reference to "link" is not helpful here. Please let me know if URL is responsive to this comment.
Change:
An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a <del> corresponding private key.  This authenticator uses the message structures from Section 4.4 of TLS13, but different parameters. Also, unlike the Certificate and CertificateRequest messages in TLS 1.3, the messages described in this draft are not encrypted with a handshake key. </del> <ins> corresponding private key.  For clients, an authenticator request is required; for servers an authenticator request is optional.  The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  Unlike the Certificate and CertificateVerify messages in TLS 1.3, the messages described in this document are not encrypted with a handshake key. </ins> Each authenticator is computed using a Handshake Context and Finished MAC Key derived from the TLS session.  These values are derived using

Discussion:
Add new "authenticator request" message Make Certificate selection more explicit (including extensions) Update API considerations accordingly
I update the draft in response to the comments.
Two small comments: Can you add text explaining why authenticator requests are not encrypted with handshake keys? (Are they encrypted at all?) It might help to include a sequence diagram or two showing intended uses of exported authenticators, e.g., for Mike's draft, and where requests fit into TLS connections.
NAME I'm not sure what purpose encrypting them would serve. The draft does say that "The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport." In other words, the messages have integrity built-in and any desire for confidentiality is the app's to solve.
NAME I was referring to the following sentence: "This message is not encrypted with a handshake key, which differs from how this message is used in TLS 1.3." Perhaps you could add text explaining why this choice was made?
By the time you use this, handshake keys might be long gone. I think that we could avoid this confusion by stating that this is only the handshake messages and not records that form the authenticator. And maybe add that because there are no records, there is no record protection.
Change:
Field type: The type of value to be provided, e.g., string, boolean, array of string <del> Client configurable: Boolean indicating whether the server should accept values provided by the client </del> <ins> Configurable: Boolean indicating whether the server should accept values provided by the client </ins> Reference: Where this field is defined

Discussion:
For pem-certificate-chain, the "Addition information" section was getting jumbled all onto one line by the Markdown to HTML generator. The table for Fields in Account Objects was jumbled. In the template for some registries, a field was called "Client configurable" in the next but "Configurable" in the table. Changed to always say "Configurable."
Change:
Description: ctls_template <del> DTLS-OK: ??? Not clear what to put here. </del> <ins> DTLS-OK: Y </ins> Reference: (This document)

Discussion:
For the ctls_template message type it is OK to set the DTLS-OK field to "Y". The entire message is not applicable to regular TLS/DTLS and hence there is no harm whatever value is in the IANA registry.
I still think it's unclear what this means, but I agree that it doesn't matter much and "Y" is ... not wrong.
Change:
this connection, while requests on the indicated stream ID and greater were rejected.  This enables client and server to agree on which requests were accepted prior to the connection shutdown.  This <del> identifier MAY be lower than the stream limit identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were processed. Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. </del> <ins> identifier MAY be zero if no requests were processed.  Servers SHOULD NOT increase the QUIC MAX_STREAMS limit after sending a GOAWAY frame. </ins> Clients MUST NOT send new requests on the connection after receiving GOAWAY; a new connection MAY be established to send additional

Discussion:
TBH I'm not sure the whole "set GOAWAY last stream id to MAXSTREAMID / maximum value allowed by MAX_STREAMS" is really necessary, but I kept it for now.
Change:
the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. <del> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue sending RTCP, as described in RFC3264, Section 5.1. </del> <ins> If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for local answers, "sendonly" for remote answers, or "inactive" for either type of answer) stop transmitting all RTP media, but continue sending RTCP, as described in RFC3264, Section 5.1. </ins> If the m= section proto value indicates use of SCTP:

Discussion:
BLOCKER: The first bullet on page 70 exhibits the same error.
Maybe I am just dumb but I am not seeing this in the text.
Sorry, I mis-entered this one. This is regarding media directionality again.
NAME PTAL and see if there's anything from that we need to do here.
Change:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL domain and ROLL. <ins> Consumed: A Routing Header is consumed when the Segments Left field is zero, which indicates that the destination in the IPv6 header is the final destination of the packet and that the hops in the Routing Header have been traversed. </ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a

Discussion:
…S and COMMENT) On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (pthubert=EMAIL) wrote: Hello Michael and all: Yes, I expected policies that would validate the right of a Leaf to participate to a DODAG ,or to remap the information from the leaf (could be the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI. Yes, as I said in my response I thought it was quite common. I'm surprised to find little art to quote. Cool, we're good! Pascal Roll mailing list EMAIL URL Roll mailing list EMAIL URL
Change:
distinguishable from other UDP traffic by a passive observer in the network. <del> The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other applications are currently being defined and deployed over QUIC, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del> <ins> At the time of writing, two application bindings for QUIC have been published or adopted by the IETF: HTTP/3 QUIC-HTTP and DNS I-D.ietf- dprive-dnsoquic.  These are both known to have active internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-

Discussion:
Looks good to me. thanks
URL, this needs examples. what about DNS over QUIC as some defined over QUIC? but I would love to get educated on the deployment part and refer that from this doc to support this statement.
Change:
4.3.18. <ins> Cryptographic keys for signing/authenticating manifests SHOULD be replaced from time to time.  Because it is difficult and risky to replace a Trust Anchor, keys used for signing updates SHOULD be delegates of that Trust Anchor. If key expiration is performed based on time, then a secure clock is needed.  If the time source used by a recipient to check for expiration is flawed, an old signing key can be used as current, which compounds threat-key-exposure. Mitigates: 4.3.19. </ins> Manifests SHOULD be verified prior to deployment.  This reduces problems that may arise with devices installing firmware images that damage devices unintentionally. Mitigates: <del> 4.3.19. </del> <ins> 4.3.20. </ins> For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an

Discussion:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.
Change:
above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. <del> If populating the "path" field: Create a UpdatePath using the new </del> <ins> If populating the "path" field: Create an UpdatePath using the new </ins> tree.  Any new member (from an add proposal) MUST be exluded from the resolution during the computation of the UpdatePath.  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial <del> GroupContext object. </del> <ins> GroupContext object.  The "leaf_key_package" for this UpdatePath must have a "parent_hash" extension. </ins> Assign this UpdatePath to the "path" field in the Commit.

Discussion:
It looks like in Commit was moved to in UpdatePath, but some docs didn't get updated.
Change:
This subsection illustrates the information model and serialization based on an example from RFC6690: <del> After an extraction (currently not defined in this document), this list represents the content of the basic information model representing the above.  For the basic model, the table is to be considered unsorted in the first step. </del> <ins> After an extraction described in convert-6690, this list represents the content of the basic information model representing the above. For the basic model, the table is to be considered unsorted in the first step. </ins> During extraction, some information on item ordering was preserved into the structured data.  Note that while the CoRAL structured data

Discussion:
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).
Change:
Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset <del> of version A. </del> <ins> of version A: if version A includes the concept of streams and STREAM frames, and version B includes the concepts of streams and tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </ins> Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the

Discussion:
LGTM.
This is a very important section, but I found it to be a little muddy. In particular, the directionality of the phrase A is compatible with B was unclear. An example would help here, I think.
Change:
In FETCH and (i)PATCH requests, the client can pass arbitrary names to the target resource for manipulation.  The resource implementer must take care to only allow access to names that are actually part <del> of (or accessible through) the target resource. </del> <ins> of (or accessible through) the target resource.  In particular the receiver needs to ensure that any input does not lead to uncontrolled special interpretation by the system. </ins> If the client is not allowed to do a GET or PUT on the full target resource (and thus all the names accessible through it), access control rules must be evaluated for each record in the pack. <del> 6. </del> <ins> 7. </ins> This document registers two new media types and CoAP Content-Format IDs for both media types.

Discussion:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.
Change:
A corollary to this statement is that the AS and the DS cannot read the content of messages sent between Members as they are not Members <del> of the Group.  MLS optionally provide additional protections </del> <ins> of the Group.  MLS optionally provides additional protections </ins> regarding traffic analysis so as to reduce the ability of adversaries, or a compromised member of the messaging system, to deduce the content of the messages depending on (for example) their

Discussion:
Remove "join an existing group" from architecture doc, based on UserAdd having been removed from the protocol doc. Remove statement that message delivery cannot be correlated between AS identities and DS delivery channels. This seems generally very difficult to achieve. It may be possible at times, but does not seem to be grounded in discussions that we have had at the working group meetings. Note that federation requires compatible wire encodings. Note that communication with the AS requires TLS or alternative authentication. Note that out-of-band channels may facilitate detection of misbehaviour. Some grammar fixes.
Change:
request with a failure, or if the datagrams are received by the proxy before the request. <del> 5. </del> <ins> 6. </ins> Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching.

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:
is determined by one of the two following methods: Compare ClientECH.config_id against identifiers of known <del> ECHConfigs and select the one that matches, if any, as a candidate. </del> <ins> ECHConfigs and select the ones that match, if any, as candidates. </ins> Collect all known ECHConfigs as candidates, with trial decryption below determining the final selection.

Discussion:
This doesn't bind anything, so no sense wasting bytes. (Note: this is orthogonal to , but it makes more sense with that PR.)
I guess this makes the text in a little odd because "Compare ClientECH.config_id against identifiers of known ECHConfigs and select the one that matches, if any, as a candidate.", is a little less clear. If we want to do this, it maybe should say "and select any that match", even though there'll really just be one match.
(Rebased and made the text talk about multiple potential matches.)
This matches the acceptance signal length, and we've already accepted that probability of collision.
I agree this is fine.
Change:
QUIC connections are established as described in QUIC-TRANSPORT. During connection establishment, HTTP/3 support is indicated by <del> selecting the ALPN token "hq" in the TLS handshake.  Support for </del> <ins> selecting the ALPN token "h3" in the TLS handshake.  Support for </ins> other application-layer protocols MAY be offered in the same handshake.

Discussion:
Section 2.3, paragraph 2 still uses "hq"
Good spot, PR fixes this
Whoops!
Change:
as specified in QUIC-TRANSPORT.  The new transport parameter is defined as follow: <del> name: enable_multipath (TBD) </del> <ins> name: enable_multipath (TBD - experiments use 0xbabf) </ins> value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available

Discussion:
For issue
Ok too.
Based on the discussed from the side meeting, we need to Clarify that the goal is to only select one approach for the finally published solution in an RFC Add some discussion about the pros and cons to the appendix
Yes, I think we should have these discussions in the current draft.
Should we use a new code point for the transport parameter of the options? For 2 reasons: It's a new joint version As we use a different value definition in our current implementation, it's hard to deploy the new version in a synchronised way, at least we could keep compatible if we use a new transport parameter. What do you think? Or maybe we should keep it unchanged until the WG is ready to adopt the draft?
I think it is fine to define a new value for the transport parameter, the 00 version of this draft is not yet out anyway.
Yes, please use a new parameter.
I created to add one more sentence and a reference to the slides from the side meeting. I believe this is sufficient to address this issue for -00.
NAME please confirm that this is okay and merge!
Change:
12.2. <del> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or appraisal policy must support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security properties, including: </del> <ins> Any solution that conveys information in any conceptual message (see messages) must support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security properties, including: </ins> end-to-end encryption,

Discussion:
Signed-off-by: Dave Thaler
** Section 12.2 Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or appraisal policy ... Should reference values be included?
same changes, conceptual messages