jiebi/CodeConvo huggingface dataset:
Change:
IDs are client-allocated, and odd-numbered context IDs are proxy- allocated.  The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be <del> simultaneously assigned different semantics in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re- allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and proxy - only allocation carries separate namespaces to avoid requiring synchronization. </del> <ins> simultaneously allocated in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re-allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and proxy - only allocation carries separate namespaces to avoid requiring synchronization. </ins> Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does

Discussion:
I'm having trouble grokking this, is the mention of "different semantics" duplicate text or is it meant to apply to different things?
Change:
by setting the "Safely Replayable" send parameter to true when sending the data.  In general, 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the SYN is retransmitted, <del> the data will be retransmitted as well), but racing means that different leaf nodes have the opportunity to send the same data independently.  If data is truly safely replayable, this should be permissible. </del> <ins> the data will be retransmitted as well but may be considered as a new connection instead of a retransmission).  Also, when racing connections, different leaf nodes have the opportunity to send the same data independently.  If data is truly safely replayable, this should be permissible. </ins> Once the application has provided its 0-RTT data, an implementation should keep a copy of this data and provide it to each new leaf node

Discussion:
I would further recommend to move this section into 4 somewhere as this section is more about connection establishment than sending messages
LGTM
Change:
Finally, the leader removes from the report sequence any report for which the corresponding state is FAILED and proceeds as described in <del> the next section. </del> <ins> the next section, even if the sequence is empty. </ins> 4.4.4.2.

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq
Change:
(i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary: <del> "right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, 1 + cid_len))) " </del> <ins> "right_0 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1), len(right_1)) " </ins> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID.

Discussion:
Discuss Distinguishing Attack in security section. Fix specification of Four Passes decryption Fix number of kramdown issues.
NAME I think this simple PR is ready.
Thank you, this is perfect.
We're awaiting more data to fully understand this, but we may need to allow 4, 6, or 12 passes as configuration options.
Fixed by , but we're instead going to go with in lieu of doing this.
The analysis in the second crypto review should be in the security considerations.
I believe there is an edge case where a partially chosen plaintext is possible. 1) The load balancer is supporting both an encrypted and unencrypted config, on different codepoints, that happen to use the same server ID mapping 2) The server is generating encrypted CIDs. 3) The attacker sends an initial packet sends an unencrypted CID. 4) Any server generated CID is therefore using the unencrypted server ID as plaintext. The random nonce should generally protect us, but maybe not? Anyway, security considerations could say something like "unencrypted and encrypted CIDs MUST NOT use the same server ID assignments because...".
Fixed by
Change:
DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in ip-flow-id.  An implementation MUST support the provisioning of handling of received DetNet MPLS <del> data plane as DetNet IP flows via configuration and the controller plane, see m-cp-considerations.  Note that such configuration MAY include support from PEOF on the incoming DetNet MPLS flow. </del> <ins> data plane as DetNet IP flows via configuration.  Note that such configuration MAY include support from PEOF on the incoming DetNet MPLS flow. </ins> <del> 7.2. </del> <ins> 7.4. </ins> The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the controller plane.  When an

Discussion:
import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP
Change:
"concat(SerializeScalar(proof[0]), SerializeScalar(proof[1]))", where Ns is as defined in OPRF, Section 4. <del> The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "application/ private-token-response". </del> <ins> The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response". </ins> 5.3. Upon receipt, the Client handles the response and, if successful, <del> deserializes the body values TokenResponse.evaluate_msg and </del> <ins> deserializes the content values TokenResponse.evaluate_msg and </ins> TokenResponse.evaluate_proof, yielding "evaluated_element" and "proof".  If deserialization of either value fails, the Client aborts the protocol.  Otherwise, the Client processes the response as

Discussion:
... I think. I'm double checking to see if there is any other improper HTTP usage.
The Issuance protocol depends on HTTP, so I'd expect this to be cited. Then we get into the HTTP terminology alignment game. For example, where the document says something like should be substituted for as per URL
Change:
The following notations, which can be combined, are used in this document: <del> An Action creates an Object: </del> <ins> An Action that creates an Object: </ins> <del> An Action creates an array of Objects: </del> <ins> An Action that creates an array of Objects: </ins> <del> An Action is performed on an Object: </del> <ins> An Action that is performed on an Object: </ins> An Object sends an Event:

Discussion:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good
Change:
as one of its primary mechanisms of technical censorship Ensafi-2013. Iran has also used Packet Dropping as the mechanisms for throttling SSH Aryan-2012.  These are but two examples of a ubiquitous <del> censorship practice. </del> <ins> censorship practice.  Notably, packet dropping during the handshake or working connection is the only interference technique observed for QUIC traffic so far, e.g. in India, Iran, Russia and Uganda Elmenhorst-2022. </ins> 5.2.3.

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:
Handling of Capabilities MUST be supported if the network uses MOPex [I-D.jadhav-roll-mopex]. <ins> Note that capabilities and MOPex are mutually exclusive and it is possible for an implementation to support either or both of the options. </ins> 3.1. <ins> Capabilities can be divided into two broad categories Global Capabilities: It will include the features and capability supported across an RPL instance.  These capabilities can be advertised by the Root or 6LRs of the DODAG.  If a Node in the LLN doesn't support a paticular global capability it may have to join the RPL instance as a leaf node, as indicated by that individual capability option.  Example of such capabilities are Compression Methods Supported, Support for TE paths (P-DAO). Local Capabilities: It will include the cpabilities very specific to a Node in the LLN.  Example of such capabilities are NBR Cache information, Routing Table Information. Note that some capabilities can be either global or local depending upon the context they are used ex.P-DAO 3.2. </ins> Multiple capabilities could be sent in the same message.  The length field allows the message parser to skip the capability TLV parsing. Every capability is identified by its type and it may have an optional Capability Info.  Note that a given capability may or may <del> not be diseminated with additional information depending on the 'I' flag. J = Join only as leaf if capability not understood C = Copy capability to children </del> <ins> not be diseminated with additional information depending on the scope of the capability indicated by the G bit.  The first Bit of the CAPType indicates if the capability is mandatory or optional Value of 1 indicates its a mandatory capability and 0 indicates its an optional capability G = If set indicates a Global Capability/Feature else its a local. For a capability if it's mandatory and global bit is set then node thoes either doesn't understand the capability or doesn't have this capability should not join the DODAG as LR.  All the global capablities MUST be desiminated across the network. </ins> I = Cap Info present

Discussion:
Modified Capabilities section.
NAME - the complete file seems to be changed! Is it because of the ^M issue? Better you can close this PR and raise another one only with the changes. Thanks
Comments for the PR.
Change:
diversify a key based on some contextual information before use in a connection.  In contrast to key exporters, wherein differentiation is done via an explicit label and context string, the key importer <del> defined herein uses an optional context string along with a target protocol and KDF identifier to differentiate an external PSK into one or more PSKs for use. </del> <ins> defined herein diversifies external one PSK into one or more PSKs for use via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs. </ins> Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. <del> Thus, importers induce no protocol changes with the exception of expanding the set of PSK identities sent on the wire.  Endpoints may incrementally deploy PSK importer support by offering non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire. See rollout for more details. </del> <ins> Endpoints may incrementally deploy PSK importer support by offering non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. </ins> Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.

Discussion:
kramdown-rfc2629 inserts a non-breaking space when expanding , which xml2rfc subsequently mangles to produce invalid XML. Rather than deal with that, insert the boilerplate with regular spaces instead. Note that this is necessary to make work properly, as that tool drops the non-breaking whitespace character between "BCP" and "14".
URL (I need to follow up regarding the use of non-breaking whitespace generally).
This seems fine, but I assume you've separately filed the appropriate bugs to fix the regular tools?
Change:
Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the respective hop.  Each HBH key is distinct per hop and no two hops <del> ever intentionally use the same SRTP master key. </del> <ins> ever use the same SRTP master key. </ins> Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.
Change:
Array slice selector "[<start>:<end>:<step>]", where the optional values "<start>", "<end>", and "<step>" are integer literals. <del> Nested descendants selector "..". </del> <ins> Descendants selector "..". </ins> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma separated list of index and slice selectors.

Discussion:
Exclude the node itself Define the term "descendants" more precisely Define the descendant selector semantics more thoroughly Fixes: URL
I would consider adding two additional examples: given: results in: - and results in: - ] ]
I extended the existing example attempting to exhibit the same points as the example above.
Looks good, thanks!
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.
I haven't checked the examples, but I like the narrative changes.
Change:
[1]. Thanks to Daniel Kahn Gillmor for a pretty detailed review of the <del> initial draft.  Thanks to Stephen Farrell, Mark Orchezowski, Martin Rex and Martin Thomson for their reviews. </del> <ins> initial draft.  Thanks to Stephen Farrell, Martin Rex Martin Thomson and employees of the UK National Cyber Security Centre for their reviews. </ins> 8.  References

Discussion:
Two sets of comments from Mark O, received after WGLC. One is a reference to the acknowledgement section, in which he would rather not see his name spelled out. The other is about residual risks of fronting server spoofing when only the hidden service is verified in TLS.
Change:
In this process, the joiner sends a new "init_secret" value to the group using the HPKE export method.  The joiner then uses that <del> "init_secret" with information provided in the GroupInfo and an external Commit to initialize their copy of the key schedule for the new epoch. </del> <ins> "init_secret" with information provided in the PublicGroupState and an external Commit to initialize their copy of the key schedule for the new epoch. </ins> Members of the group receive the "kem_output" in an ExternalInit proposal and preform the corresponding calculation to retrieve the "init_secret" value. <del> In both cases, the "info" input to HPKE is set to the GroupInfo for the previous epoch, encoded using the TLS serialization. </del> <ins> In both cases, the "info" input to HPKE is set to the PublicGroupState for the previous epoch, encoded using the TLS serialization. </ins> 8.2.

Discussion:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Change:
A client or Oblivious Relay Resource MUST NOT automatically attempt to retry a failed request unless it receives a positive signal indicating that the request was not processed or forwarded.  The <del> HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred. Connection failures or interruptions are not sufficient signals that no processing occurred. </del> <ins> HTTP/2 REFUSED_STREAM error code (HTTP2), the HTTP/3 H3_REQUEST_REJECTED error code (HTTP3), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred.  Connection failures or interruptions are not sufficient signals that no processing occurred. </ins> The anti-replay mechanisms described in TLS are generally applicable to Oblivious HTTP requests.  The encapsulated keying material (or

Discussion:
This would have been easier had I not forgotten how to do this.
Does this ref need to be normative?
oh, it seems this relates to a the registration of buried down in Section 10.2. Is this still valid?
Yes it is, though I realize that we also buried the IANA considerations a little too deep.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.
Change:
according to the TSN Stream specific configuration to connected CE(s) (in case of local bridging) and/or to the DetNet Service Proxy (in case of forwarding to remote CE(s)).  If there are no TSN Stream <del> specific forwarding configurations the PE MUST flood the packet to </del> <ins> specific forwarding configurations, the PE MUST flood the packet to </ins> other locally attached CE(s) and to the DetNet Service Proxy.  If the <del> administrative policy on the PE does not allow flooding the PE MUST </del> <ins> administrative policy on the PE does not allow flooding, the PE MUST </ins> drop the packet. When a TSN entity of the PE receives a packet from the DetNet Service Proxy, it first checks via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a <del> configured TSN Stream.  If no Stream ID is matched then packet is dropped.  If there is a matching TSN Stream then the Stream ID </del> <ins> configured TSN Stream.  If no Stream ID is matched, then packet is dropped.  If there is a matching TSN Stream, then the Stream ID </ins> specific TSN functions are executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup may also be used for local MAC address learning. If the PE decides to forward the packet, the packet is forwarded according to the TSN Stream specific configuration to connected <del> CE(s).  If there are no TSN Stream specific forwarding configurations the PE floods the packet to locally attached CE(s).  If the administrative policy on the PE does not allow flooding the PE drops the packet. </del> <ins> CE(s).  If there are no TSN Stream specific forwarding configurations, the PE floods the packet to locally attached CE(s). If the administrative policy on the PE does not allow flooding, the PE drops the packet. </ins> Implementations of this document SHALL use management and control information to ensure TSN specific functions of the Edge Node

Discussion:
Adding commas, the editor will probably catch these.
Hi Don, many thanks for the review. Cheers Bala'zs