jiebi/CodeConvo huggingface dataset:
Change:
Each Issuance protocol MUST come with a detailed analysis of the privacy impacts of the protocol, why these impacts are justified, and <del> guidelines on changes to the parametrization in parametrization. </del> <ins> guidelines on how to deploy the protocol to minimize any privacy impacts. </ins> Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some

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:
the SNI remains the primary explicit signal used to determine the server's identity. <del> The TLS WG has extensively studied the problem of protecting the SNI, </del> <ins> The TLS Working Group has studied the problem of protecting the SNI, </ins> but has been unable to develop a completely generic solution.  I- D.ietf-tls-sni-encryption provides a description of the problem space and some of the proposed techniques.  One of the more difficult

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
HTTP_MISSING_SETTINGS.  Only one control stream per peer is permitted; receipt of a second stream which claims to be a control stream MUST be treated as a connection error of type <del> HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control </del> <ins> HTTP_STREAM_CREATION_ERROR.  The sender MUST NOT close the control </ins> stream, and the receiver MUST NOT request that the sender close the control stream.  If either control stream is closed at any point, this MUST be treated as a connection error of type

Discussion:
There are presently several kinds of very similar error when creating streams: HTTPUNKNOWNSTREAMTYPE MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer. It is not a connection error. HTTPWRONGSTREAMCOUNT MUST be used if a peer tries to open more than one critical stream (control, QPACK). Connection error. HTTPWRONGSTREAMDIRECTION MUST be used if a client tries to open a push stream. More generally this could be used if a peer attempts to open a stream type that is not allowed to, but push is the only example today. Connection error. The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION. The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop. PS. The eagle eyes will notice I omitted the HTTPDUPLICATE_PUSH creation error. This is on the chopping block in . I class it differently because it is about parsing information after the stream type.
Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream? At the moment the designated error code is HTTPGENERALPROTOCOLERROR, but STREAMCREATIONERROR might be a better fit. Or if we are not going to use STREAMCREATIONERROR for server-initiated bidirectional streams, I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion.
This relates to some earlier discussion on URL and its now-merged PR URL We only recently added text to specify the use of HTTPGENERALPROTOCOLERROR in this case, I think it fits to modify this to STREAMCREATION_ERROR.
Changed in URL
Change:
Delivery Service, the functionnal and security guarantees provided by MLS may differ. <del> 2.3.1. </del> <ins> 2.2.1. </ins> In the MLS group communication establishment process, the first step exercised by the DS is to store the initial cryptographic key

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
used instead. When creating an IceCandidate object, JSEP implementations MUST <del> populate all of these fields. </del> <ins> populate each of the candidate, ufrag, m= section index, and MID fields.  Implementations MUST also be prepared to receive objects with some fields missing, as mentioned above. </ins> 3.5.3.

Discussion:
Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. Please state precisely which fields you mean.
Yeah, OK.
Change:
of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules <del> (TPMs), or BIOS firmware. </del> <ins> (TPMs) TCGarch, or BIOS firmware. </ins> An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.  Execution

Discussion:
added reference to TEEP, cited TPM reference in section 3.3.
First mentioning of TEE, eSE, and TPM need reference in section Two Types of Environments of an Attester.
These terms need to have references: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.
We don't think we need to expand BIOS, and that it should be on the RFC editor Acronym list.
Change:
alternative to IPsec.  A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports.  OpenVPN encapsulates either IP packets or Ethernet <del> frames within a secure tunnel and can run over UDP or TCP. </del> <ins> frames within a secure tunnel and can run over UDP or TCP.  For key establishment, OpenVPN can use TLS as a handshake protocol or pre- shared keys. </ins> 4.

Discussion:
This PR mainly changes the beginning of Section 3, Transport Security Protocol Descriptions. It substitutes the sentence on how the document is structured (which I moved to the Introduction) with a brief discussion on the classification we use in Section 3. This includes an explanation of the difference between handshake and record protocols as suggested by Ekr. Furthermore, this PR references DTLS-SRTP, renames "QUIC + TLS" to "IETF QUIC", and mentions that OpenVPN can use TLS as a handshake protocol.
Thank you!
Change:
Verify that the "encryption_key" value in the LeafNode is different from the committer's current leaf node. <del> Compute parent hashes for the parent nodes in the UpdatePath (relative to the new ratchet tree) and verify that the "parent_hash" field of the leaf node matches the parent hash for the first node its filtered direct path. </del> <ins> Merge the UpdatePath into the new ratchet tree as described in synchronizing-views-of-the-tree. </ins> Construct a provisional GroupContext object containing the following values:

Discussion:
Conflicts with (in derivation of ) This is intended just to move around the required steps and give them clearer labels. Please keep an eye out for things that might have accidentally been added or dropped.
Interim 2022-06-02: NAME to review, then clear to merge
Currently, we only have explicit algorithm steps for validating an UpdatePath. We should have a similar level of concreteness for the process of creating an UpdatePath.
Change:
The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the <del> IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del> <ins> IANA allocated TCP System Port (WEBPUSH-PORT) using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios

Discussion:
Based on the IANA review: Update IANA Considerations to indicate the System Port 1001 is a suggestion Update inline references to 1001 to "TBD"
LGTM (I'll let you merge this one).
Change:
reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical. <del> 3. </del> <ins> 3.4. An RFC 3339 timestamp can contain a "time-offset" value that indicates the offset between local time and UTC (see RFC3339, noting that update of the present specification updates RFC3339). The information given in such a "time-offset" value can be inconsistent with the information provided in a time zone suffix for an IXDTF timestamp. For example, a calendar application could store an IXDTF string representing a far-future meeting in a particular time zone.  If that time zone's definition is subsequently changed to abolish Daylight Saving Time, IXDTF strings that were originally consistent may now be inconsistent. In case of inconsistent "time-offset" and time zone suffix, if the critical flag is used on the time zone suffix, an application MUST act on the inconsistency.  If the critical flag is not used, it MAY act on the inconsistency.  Acting on the inconsistency may involve rejecting the timestamp, or resolving the inconsistency via additional information such as user input and/or programmed behavior. For example, the IXDTF timestamps in example-inconsistent represent 00:14:07 UTC, indicating a local time with a "time-offset" of +00:00. However, because Europe/London used offset +01:00 in July 2022, the timestamps are inconsistent: As per RFC3339 as updated by update, IXDTF timestamps may also forego indicating local time information in their RFC3339 part.  The IXDTF timestamps in example-consistent (which represent the same instant in time as the strings in example-inconsistent) are not inconsistent because they do not assert any particular local time nor local offset in their RFC3339 part.  Instead, applications that receive these strings can base their local offset and local time calculations on the time zone suffix given, i.e., using the Europe/London time zone rules. </ins> <del> 3.1. </del> <ins> 4. 4.1. </ins> The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix.

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: <del> Data transport: TCP, UDP and the means to securely set up </del> <ins> Data transport: such as TCP, UDP and the means to securely set up </ins> connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on.

Discussion:
Mirja had the following comment: section 3: "Data transport: TCP, UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on." This seems to implicitly assume that only TCP or something encapsulated over UDP can be used. Even though that might be true, I assume this was not intentionally, maybe: NEW "Data transport: such as TCP or UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on."
Change:
Git is not the only version control system available, nor is GitHub the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional <del> features to GitHub.  For instance, BitBucket [6] and GitLab [7] </del> <ins> features to GitHub.  For instance, BitBucket [3] and GitLab [4] </ins> provide similar feature sets.  In addition to a hosted service, software for custom installations exists.

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
idempotency related requirements as published by the server and use appropriate algorithm to generate idempotency keys. <del> For each request, client SHOULD </del> <ins> For each request, client </ins> Send a unique idempotency key in the HTTP "Idempotency-Key" request header field.

Discussion:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.
Change:
The initial probe timeout for a new connection or new path SHOULD be set to twice the initial RTT.  Resumed connections over the same <del> network SHOULD use the previous connection's final smoothed RTT value as the resumed connection's initial RTT.  If no previous RTT is </del> <ins> network MAY use the previous connection's final smoothed RTT value as the resumed connection's initial RTT.  If no previous RTT is </ins> available, the initial RTT SHOULD be set to 500ms, resulting in a 1 second initial timeout as recommended in RFC6298.

Discussion:
The recovery draft says: "Resumed connections over the same network SHOULD use the previous connection's final smoothed RTT value as the resumed connection's initial RTT." I wonder if we should change this to a MAY, as there is also a temporal aspect. Or maybe we should say more about this? Also note that draft-ietf-tcpm-2140bis is probably related.
I would agree with switching to MAY. Even mentioning this leads to some incentive to implement, so the effect on implementation is similar. But we really don't need to recommend something like this.
Change:
This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's browser.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </del> <ins> is used in full trickle mode with a bundle policy of max-bundle, an RTCP mux policy of require, and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's browser.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </ins> The SDP for |offer-B1| looks like:

Discussion:
Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed
Change:
if it received a Version Negotiation packet that listed the versions in the server's Other Versions field, plus the negotiated version. If the client would have selected a different version, the client <del> MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR.  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </del> <ins> MUST close the connection with a version negotiation error.  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </ins> This validation of Other Versions is not sufficient to prevent downgrade.  Downgrade prevention also depends on the client ignoring

Discussion:
Defining an error code for QUICv1 is good, but I think that you need to frame this differently. It probably needs to be framed in terms of a requirement on all QUIC versions. So rather than: You might say something like:
I like this. Can you make it a PR?
Change:
If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. <del> 7.3. </del> <ins> 7.5. </ins> When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original.

Discussion:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.
Change:
acceptable provided that the features of TLS 1.3 that are used by QUIC are supported by the newer version. <del> A badly configured TLS implementation could negotiate TLS 1.2 or another older version of TLS.  An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated. </del> <ins> Clients MUST NOT offer TLS versions older than 1.3.  A badly configured TLS implementation could negotiate TLS 1.2 or another older version of TLS.  An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated. </ins> 4.3.

Discussion:
Just in case this wasn't blindingly obvious.
The TLS spec says: version of TLS. An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated. I would propose that we forbid clients from offering 1.2 or older [and maybe require servers to enforce this].
Change:
resource server.  In order to provide communication security, proof of possession, and server authentication they use Object Security for Constrained RESTful Environments (OSCORE) I-D.ietf-core-object- <del> security.  Optionally the client and the resource server may also use CoAP and OSCORE to communicate with the authorization server. </del> <ins> security. </ins> OSCORE specifies how to use CBOR Object Signing and Encryption (COSE) <del> RFC8152 to secure CoAP messages.  In order to provide replay and reordering protection OSCORE also introduces sequence numbers that are used together with COSE. Note that OSCORE can be used to secure CoAP messages, as well as HTTP and combinations of HTTP and CoAP; a profile of ACE similar to the one described in this document, with the difference of using HTTP instead of CoAP as communication protocol, could be specified analogously to this one. </del> <ins> RFC8152 to secure CoAP messages.  Note that OSCORE can be used to secure CoAP messages, as well as HTTP and combinations of HTTP and CoAP; a profile of ACE similar to the one described in this document, with the difference of using HTTP instead of CoAP as communication protocol, could be specified analogously to this one. </ins> 1.1.

Discussion:
restructuring for readability adding a section for protocol overview adding examples for each message adding details about updating clients rights (request new token with only scope different) where before there were ref to the framework, explicitly state all the normative text add mechanism during OSCORE Setup for making sure the context is not reused on the server if token is re-posted after it has been lost/removed (nonces) added section about access rights verification between OSCORE layer and CoAP (handling of the resource) layer
Change:
between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks. <del> The application is interactive.  Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm), to prefer lower-latency paths, signal a preference for lower-latency, higher-loss treatment, and so on. </del> <ins> Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation when sending this message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on. </ins> The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should <del> be optimized at the expense of bandwidth efficiency.  This implies </del> <ins> be minimized at the expense of bandwidth efficiency.  This implies </ins> that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate

Discussion:
Removes Immediate Acknowledgment and makes it an optional implicit feature of Low Latency profile, renames Instantaneous Capacity Profile to Transmission Profile. Addresses ; we should open a new issue to discuss whether we want to split Capacity Profile back out.
About "Transmission profile", I like it; we had Capacity Profile (not "Instantaneous" though) in NEAT because it contains choices about how an application wants to make use of the available capacity. Because "Transmission profile" loses that hint, it conveys less meaning - but frankly, I still prefer it just for the way it sounds.