jiebi/CodeConvo huggingface dataset:
Change:
time, a strict bound SHOULD be applied to the active number of Issuers in the ecosystem.  We propose that allowing no more than 4 Issuers at any one time is highly preferable (leading to a maximum of <del> 64 possible user segregations).  However, as highlighted in parametrization, having a very large user base (> 5 million users), could potentially allow for larger values.  Issuer replacements </del> <ins> 64 possible user segregations).  However, having a very large user base could potentially allow for larger values.  Issuer replacements </ins> should only occur with the same frequency as config rotations as they can lead to similar losses in anonymity if clients still hold redemption tokens for previously active Issuers.

Discussion:
After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.
Change:
of the group, who apply it to keep their local views of the tree in sync with the sender's.  When a client commits a change to the tree (e.g., to add or remove a member), it transmits a handshake message <del> containing a set of public values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these public values to update their view of the tree, aligning their copy of the tree to the sender's. </del> <ins> containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these values to update their view of the tree, aligning their copy of the tree to the sender's. </ins> To perform an update for a path (a Commit), the sender broadcasts to the group the following information for each node in the direct path

Discussion:
This PR adds a fix mentioned in but was not included in the PR that was eventually merged. Specifically, both public and encrypted private values are sent in a message containing key material to ratchet the tree forward.
Change:
ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances <del> are able accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. </del> <ins> are able to accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. </ins> During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do

Discussion:
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 URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Change:
AbortGroup: Calling "AbortGroup" calls ABORT.SCTP, immediately closing all Connections in the SCTP association. <ins> In addition to the API mappings described above, when there are multiple Connection objects assigned to the same SCTP association, SCTP can support Connection properties such as "connPriority"and "connScheduler" where CONFIGURE_STREAM_SCHEDULER.SCTP can be called to adjust the priorities of streams in the SCTP association. </ins> 11. RFC-EDITOR: Please remove this section before publication.

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!
Change:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230:

Discussion:
This change both describes the existing mechanism (SETTINGS). It also adds a header in the unlikely scenario that we would need to change capsule stream format (instead of just defining new capsules).
Change:
A server operates both the and the <ins> separate-target discusses the security implications for a case where different servers operate the and . </ins> Requests from the to and from to MUST use HTTPS in order to provide <del> unlinkability in the presence of a network observer.  The scheme of the determines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server- responsibilities. </del> <ins> unlinkability in the presence of a network observer. </ins> To achieve the stated privacy goals, the cannot be operated by the same entity as the . However, colocation of the and simplifies the

Discussion:
This talks about the odd case where target and gateway are separate. The primary insight here is that the target is just a regular HTTP resource and the requests from the gateway aren't special. Problems only occur if the gateway is privileged in some way. If abuse comes via the gateway, then the target would ordinary block the client, which tends to affect a bunch of bystanders in this model. So there is pressure to do something special for the gateway. In that case, the target is trusting the gateway in some way. Explain that. The heading here is the only case where we use the short names of the entities, but I can't stand short headings.
The changes are a big step forward in the right direction, but the flow seems a little weird as the text in the first part of the security section is about co-located gateway/target. Strongly suggest to move the added new text at the end of the whole section and add a forward reference in the text: (from the intro in the security section)
And, just to be clear, the PR text addresses my concern. My comment about the flow is just editorial.
I've taken the suggestion to move the text (with forward references) and made a few tweaks: Rebased. Moved and rewritten some text from the top of the security considerations that better fit the new section. Added a forward reference to this section. Moved and rewritten text added in to the applicability section. (Originally this was just to correct a misspelling, but I think this makes more sense in the new home.) NAME can you double-check my work. With this, I think we're ready to revise the draft and ask the IESG to finalize their ballot.
Change:
less responsive to changes in the path's RTT, resulting in either delayed or unnecessary packet transmissions. <del> To limit these consequences of reduced acknowledgement frequency, a sender SHOULD cause a receiver to send an acknowledgement at least once per RTT if there are unacknowledged ack-eliciting packets in flight.  A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. </del> A sender might use timers to detect loss of PMTU probe packets (Section 14 of QUIC-TRANSPORT).  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMU probes to avoid triggering such

Discussion:
We had similar text in the two sections, and the latter one was where the SHOULD was, so this consolidates the duplicate text into the Congestion Control section. This is intended as an editorial cleanup prior the the PR for
Change:
When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bits of the header are both set to 0.  Then the <del> Destination Connection ID needs to be extracted to calculate the Initial secret using the version-specific Initial salt, as described in Section 5.2 of QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID itself. </del> <ins> Destination Connection ID needs to be extracted from the packet.  The Initial secret is calculated using the version-specific Initial salt, as described in Section 5.2 of QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID itself. Note that subsequent Initial packets might contain a Destination Connection ID other than the one used to generate the Initial secret. Therefore, attempts to decrypt these packets using the procedure above might fail unless the Initial secret is retained by the observer. </ins> To determine the end of the header and find the start of the payload, the packet number length, the source connection ID length, and the

Discussion:
Addresses
... doesn't make it clear that only the Initial from the client (and only those sent before receiving packets from the server) contain a Destination Connection ID field that can be used to decrypt the packet. Any initial from the server, or any initial sent by a client after receiving Initial packets from the server, probably won't work.
Hmm, this is the last paragraph. Too late?
More broadly, it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately. We wouldn't want people to bind to a 2-tuple of CIDs and have that immediately fail.
NAME I create PR based on your comment. Is that sufficient? NAME which section are you talking about?
I think will fix NAME comment here.
Much better. My comment here is mostly a nit. I think that you are implicitly talking about the first packet from the client, so maybe you can avoid using the "Client Initial" thing here (if you are using the abstract concept you introduced), "client Initial" (that is, Initial packets sent by a client), or anything that might be confusing.
Change:
The procedures and practices employed by a certification authority MUST ensure that the correct values for the EKU extension are inserted in each certificate that is issued.  Unless certificates are <del> governed by a vendor specific PKI (or trust program), certificates that indicate usage for document signing MAY include the id-kp- documentSigning KeyPurposeId.  The inclusion of the id-kp- documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </del> <ins> governed by a vendor(s) specific PKI, certificates that indicate usage for document signing MAY include the id-kp-documentSigning KeyPurposeId.  The inclusion of the id-kp-documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </ins> 6.

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."
Change:
These examples use HTTP/2 style formatting from RFC7540. <del> For this example assume a DNS API server is following this specification on origin https://dnsserver.example.net/ and the well- known path.  The DNS API client chooses to send its requests in application/dns-udpwirefomat but indicates it can parse replies in that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del> <ins> These examples use a DNS API service located at https://dnsserver.example.net/dns-query.  The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </ins> The same DNS query, using the POST method would be:

Discussion:
and
The draft says: But it probably needs to describe at least one way to perform that automated discovery. It's probably not a good idea to have people attempt to guess.
fwiw the .wk is used here so that that when a request/response pair is pushed the client understands this to be DoH. Its probably also helpful to have a well-known path here for the normal so that defaults of https://, 443, and the default path can be used in configuration systems that might only be capable of a hostname. (e.g. my DoH server is at URL).. I'll work on text.
I think I can future proof for the context I want using a response header instead of a well known.. imo that's kind of ignoring the point of the path - but whatever. Maybe I'll propose x-well-known :)
Change:
the active stream identification function is used to modify the Ethernet header according to the ID of the mapped TSN Stream. <del> IEEEP8021CBdb defines a Mask-and-Match Stream identification function that can be used as a passive function for MPLS DetNet flows. </del> <ins> Clause 6.8 of IEEEP8021CBdb defines a Mask-and-Match Stream identification function that can be used as a passive function for MPLS DetNet flows. </ins> <del> IEEE8021CB defines an Active Destination MAC and VLAN Stream identification function, what can replace some Ethernet header fields namely (1) the destination MAC-address, (2) the VLAN-ID and (3) priority parameters with alternate values.  Replacement is provided for the frame passed down the stack from the upper layers or up the stack from the lower layers. </del> <ins> Clause 6.6 of IEEE8021CB defines an Active Destination MAC and VLAN Stream identification function, what can replace some Ethernet header fields namely (1) the destination MAC-address, (2) the VLAN-ID and (3) priority parameters with alternate values.  Replacement is provided for the frame passed down the stack from the upper layers or up the stack from the lower layers. </ins> Active Destination MAC and VLAN Stream identification can be used within a Talker to set flow identity or a Listener to recover the

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
authentication modules.  "sMTA" is the sending MTA, and "rMTA" is the receiving MTA. <del> In essence, the steps are as follows: </del> <ins> Issue 2, Original text to be deleted and/or repurposed: Issue 2, Proposed replacement text: </ins> 5.

Discussion:
Proposed updated ASCII art for mail flow. Proposed stripped down description of ASCII art. Proposed new text for Domain Owner actions.
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> The grammatical rules in this document are to be interpreted as ABNF, as described in RFC5234. </ins> 2. I-Regexps should handle the vast majority of practical cases where a

Discussion:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by
Change:
to-glass delay target under 10 seconds. This level of latency is targeted to have a user experience similar <del> to traditional broadcast TV delivery.  A frequently cited problem with failing to achieve this level of latency for live sporting events is the user experience failure from having crowds within earshot of one another who react audibly to an important play, or from users who learn of an event in the match via some other channel, for example, social media, before it has happened on the screen showing the sporting event. </del> <ins> to broadcast TV delivery.  A frequently cited problem with failing to achieve this level of latency for live sporting events is the user experience failure from having crowds within earshot of one another who react audibly to an important play, or from users who learn of an event in the match via some other channel, for example, social media, before it has happened on the screen showing the sporting event. </ins> Applications requiring low-latency live media delivery are generally feasible at scale with some restrictions.  This typically requires

Discussion:
From NAME
NAME - thank you for this review. You caught a lot more things than I was hoping were still in there. :grinning:
PR should address these issues (and more).
Agree with NAME that this fixed lots of stuff. I'd like to leave it open so we can run this tool again after addressing more issues.
Change:
authenticated so that it can be attributed to the oblivious request resource; see key-configuration. <ins> Since clients connect directly to the proxy instead of the target, application configurations wherein clients make policy decisions about target connections, e.g., to apply certificate pinning, are incompatible with Oblivious HTTP.  In such cases, alternative technologies such as HTTP CONNECT (Section 9.3.6 of HTTP) can be used.  Applications could implement related policies on key configurations and proxy connections, though these might not provide the same properties as policies enforced directly on target connections.  When this difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance. </ins> Clients MUST NOT include identifying information in the request that is encapsulated.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might

Discussion:
This may not be obvious, so perhaps good to note.
I'll move most of the text to the client section, leaving a pointer in the proxy section.
It probably depends. One could fetch the HPKE key and apply policy for each OHTTP message, which would be equivalent to applying policy for each HTTP connection if you were not using OHTTP, or one could fetch and apply policy to the HPKE key for many OHTTP messages. The results are different.
NAME this should be good to go.
Thanks for changing it up. I'm not 100% on the structure of this yet, but it is more important to get the info in place.
Change:
hash computations.  Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" <del> message, as described in the-transcript-hash. </del> <ins> message, as described in the-transcript-hash.  Note that the "message_hash" will be hashed with the negotiated function, which may or may match the hash associated with the PSK.  This is consistent with how the transcript is calculated for the rest of the handshake. </ins> 4.2.11.3.

Discussion:
The function is defined using a function . URL This is presumably the KDF hash of the cipher suite, but this doesn't seem to be written down anywhere. The Key Schedule section says: URL I can't find corresponding text in the various other calls. We could define this globally in the Transcript Hash section, and indeed that fits with the claim that "In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash." But then we have another problem... The PSK binder is also defined in terms of Transcript-Hash. Like the other text, it does not define what Hash is. URL But the default definition doesn't work for the client, in two different ways: At the first ClientHello, the cipher suite hash algorithm isn't even known yet, so we cannot possibly use that one. At the second ClientHello, we have a cipher suite hash algorithm, but it may not necessarily match the PSK's one. To keep all everything injective, both need to be the PSK hash. Though this results in another subtlety which, while not ambiguous, maybe we should change: At the second ClientHello, there are two uses of Hash. There's the overall hash, which is stuck being the PSK one, and there's the funny . That one being the PSK's hash breaks the whole notion of the transcript being this append-only thing and is a huge pain. To compensate, we allowed the second ClientHello to . That works, but it's a pretty weird edge case and easily a source of bugs. What if we changed it to be the negotiated hash? It won't affect interop, since this PSK is guaranteed not to be negotiated. The client may as well fill in all zeros for the binder. It's also still injective, as long as everyone agrees that's the one we use. The transcript includes an unhashed HelloRetryRequest immediately after messagehash, so that fixes the choice of hash. (Plus we only have two hashes right now and they're different sizes...)
Change:
Using Multicast DNS to protect privacy when exposing ICE candidates <del> draft-ietf-rtcweb-mdns-ice-candidates-00 </del> <ins> draft-ietf-rtcweb-mdns-ice-candidates-01 </ins> Abstract

Discussion:
Followup from , as discussed today
Will wait for LGTM from NAME before merging.
Rethought my approach here and rewrote the section accordingly. PTAL.
LGTM
Sorry for the delay. Github did not let me see any diffs over the weekend.