jiebi/CodeConvo huggingface dataset:
Change:
To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> keys for encryption algorithms.  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privacy impact; see multiple-configs. These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. </del> <ins> keys for encryption algorithms.  In many cases, the load balancers can distinguish these configurations by external IP address. However, assigning multiple entities to an IP address is complimentary with concealing DNS requests (e.g., DoH RFC8484) and the TLS Server Name Indicator (SNI) (I-D.ietf-tls-esni) to obscure the ultimate destination of traffic.  While the load balancer's fallback algorithm (fallback-algorithm) can use the SNI to make a routing decision on the first packet, there are three ways to route subsequent packets: all co-tenants can use the same QUIC-LB configuration, leaking the server mapping to each other as described above; co-tenants can be issued one of up to three configurations distinguished by the config rotation bits (config-rotation), exposing information about the target domain to the entire network; or tenants can use 4-tuple routing in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. When configuring QUIC-LB, administrators must evaluate the privacy tradeoff considering the relative value of each of these properties, given the trust model between tenants, the presence of methods to obscure the domain name, and value of address migration in the tenant use cases. As the plaintext algorithm makes no attempt to conceal the server mapping, these deployments SHOULD simply use a common configuration. </ins> 11.5.

Discussion:
Sec 11.4 recommends either separating mistrustful servers by IP, or assigning them different config rotation bits. The text is not adequate. Separating by IP address undermines the privacy value of ECHO & DoH (see the MAPRG IETF 110 talk) Any sub-IP routing has to be SNI-switched; if ECHO is operating, the load balancer must be a "client-facing server" in the ECHO architecture (draft-ietf-tls-esni Sec 3.1). Doing SNI switching as an ECHO server and then just encoding the result in the config rotation bits leaks the information they're trying to conceal. It might be worth it to fix up the "arbitrary algorithm" text to consider possible SNI switching. As we migrate towards ECHO and DoH, maybe the best we can do is give all tenants on an IP the same config and try to obscure their co-tenancy as much as possible.
Change:
If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by <del> setting its mid attribute to null. </del> <ins> setting its mid property to null, and discard the mapping between the transceiver and its m= section index. </ins> If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step),

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
The AS SHOULD NOT re-use subject identifiers for multiple different ROs. <del> Note: the "formats" and "assertions" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </del> <ins> Note: the "sub_id_formats" and "assertion_formats" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </ins> [[ See issue #43 [1] ]]

Discussion:
with array of objects to account for the possibility of several assertions
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 92ab3a878b0995957e39ff9c8cae0726a0fd3f44 Inspect the deploy log: Browse the preview:
As a completely random comment, I find it interesting that computer science commonly refers to an array as a collection of elements with the same data type. It's also a fixed-size collection of elements. URL clearly defines and uses an array. Moreover, it says that what's a bit more important is that this specification should probably use "array of ..." everywhere as this isn't true right now. I see the use of both "list of ..." and "array of ..." at the same time.
Since GNAP is based around JSON for its data model, we use JSON-native data types and their names. The name for an unlabeled, ordered collection is a "JSON array", as you pointed out. If there are places in GNAP where we're using "list" where we should be saying "array", we should fix that.
Todo : inner description to change (key) assertions -> format subid_formats or something like that
Requesting User Information: Editor's note: The values are lifted from ]'s "token type identifiers" list, but is there a better source? : Identifying the User: Editor's note: The keys are lifted from [RFC8693]'s "token type identifiers" list, but is there a better source? Additionally: should this be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway? Returning User Information: Editor's note: Should be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway?
A related topic is , ZKP, etc. A specific type of assertion is used in to prove ownership of a sub (through JWT).
I think that should be an in "Returning User Information". If not, at least, it could be renamed to "assertion" because the current draft uses "assertions" and defines it as . This is a minor editorial thing though. The more major thing is that what are the strong reasons even to mention SAML assertions in the spec?

In recent times, XML is often referred to as a potentially insecure format which isn't great due to a long list of vulnerabilities in XML libraries.
We'll discuss that and more at IETF110. I agree that assertions are probably an array (it's not just editorial, and there's another issue open on that) + for the very same reasons you mention I would suggest we remove saml2 assertions from the core (but still we can plan an extension in the registry, already mentioned as a possibility ).
There's now a security consideration related to XML.
Change:
12. <ins> This document provides an architecture for doing remote attestation. No specific wire protocol is documented here.  Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.  The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). </ins> 12.1. Implementers need to pay close attention to the protection of the

Discussion:
Many of the things that we are writing in the security considerations are really security requirements on implementations, rather than concerns with the architecture.
Change:
acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid.  Receipt of an invalid value MUST be treated as a <del> connection error of type FRAME_ENCODING_ERROR. </del> <ins> connection error of type FRAME_ENCODING_ERROR.  If an endpoint receives an ACK-eliciting threshold value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable value instead. </ins> A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC-

Discussion:
Does it make sense to specify any maximum values for any of the ACK frequency frame fields, such as for Packet Tolerance? Does a value of 4 billion make sense? Can I use a in my implementation to store this locally? Is there any expectation around the sizes of these fields? If there is no explicit max, what if I implicitly apply one? I'm working on implementing this and I'm trying to figure out how small (byte size) I can make the variables I use to store the values on the connection.
Update Max Ack Delay will be limited by the Max Ack Delay limit once lands. That leaves Packet Tolerance, which I agree is reasonable to limit to a value smaller than 2^62-1 locally. We could add a comment like "Implementations that have a lower limit than 2^62-1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received."
Slight tweak: "If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable maximum value instead."
Change:
The Privacy Pass issuance protocol, described in ISSUANCE, is a two- message protocol that takes as input a TokenChallenge from the redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token <del> (AUTHSCHEME, Section 2.2), as shown in the figure below. </del> <ins> (AUTHSCHEME, Section 2.2), as shown in fig-overview. </ins> The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used;

Discussion:
This is a little hard to process... An inbound PR I have proposes a change to the first diagram that might help here. A little work on this is probably necessary. !
A few things: When drawing arrows on lines, the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line: This puts the arrow on the line, which renders a gap in the line. Avoid this: The bottom-left corner here is not curved, because the detection of corners needs three characters: the corner and a line either side of that, so... Not:
NAME can you say more about how it's hard to process? As we recently discussed, we're burdened by being too close to this work, so it's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR. Is it not clear who touches or sees each message? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be! The architecture does not require the attester to be inline, it really only requires that the token request from a client be somehow blessed by the attester. I'll think about ways to better visualize this, but clarification about the source of confusion would be super helpful.
For me, the hardest part of these diagrams is that the start and end of the end of the arrows aren't really attached to anything in particular. You rely on horizontal alignment a fair bit (the arrow starts approximately under the label "Issuer", so it's probably a message from the issuer). In comparison, the diagram I provided had lines and boxes connecting them. This is probably a more illustrative example: ! Are the TokenRequest and TokenResponse labels on the lines? Where do these arrows start? Is the Client/Attester/Issuer box a single entity (obviously, no) given how the challenge arrows hit it. Which entities perform attestation? Then there are the formatting issues, some of which I will concede are specific to aasvg, see the above comment.
Thanks -- that's helpful. I think should resolve the confusion.
Change:
Connections adds a third Connection to the Connection Group, and so on.  Connections in a Connection Group generally share Connection Properties.  However, there may be exceptions, such as "Priority <del> (Connection)", see conn-priority. </del> <ins> (Connection)", see conn-priority.  Like all other Properties, Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Priority on one Connection does not change it on the other Connections in the same Connection Group. </ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection:

Discussion:
Make clearer what "Priority is not entangled" means, following . Also added a note that Clone() may result in on-the-wire signaling.
Section 11.1.3 of the API says about Priority: "As noted in Section 6.4, this property is not entangled when Connections are cloned." Not sure what this means. I though when you clone a connection you would actually take the priority of the cloned connection but then you can change it independently for each connection in a group. Or what's the priority after cloning? Back to the default of 100? We should say this explicitly. Or maybe you even want to provide the priority while cloning? Actually looking at this now again, I think we would need to specify cloning a bit better anyway. I assume that calling clone() on a multiplexing capable connection would create a new stream; in case of quic is would only create local state but no on-the-wire singling. However if you call clone on a TCP connection, is that basically an initial() call that triggers the TCP handshake? We should say this explicitly.
I'd say it's exactly as you thought: When you clone a Connection, all Properties are copied (including the Priority), but then they are not entangled: If you change the Priority on the cloned Connection, the Priority on the original Connection stays as it was. If Priority was entangled, then it would change on both Connections if you change it on one of them. But yes, perhaps this is confusing and the text should be more explicit. The part on specifying cloning better: There's text on this in the Implementation draft on what happens with Clone() for each protocol. But maybe we can say in the API document that Clone() might trigger on-the-wire signaling or it might not, depending on the protocol.
Yes, both additions/clarification would be good.
LGTM - and thanks for adding this clarification!Thank you for the clarifications!
Change:
to ensure that each report appears at most once in a batch.  (See anti-replay.) <ins> "extensions" is a list of extensions to be included in the Upload flow; see upload-extensions. </ins> "encrypted_input_shares" contains the encrypted input shares of each of the aggregators.

Discussion:
One possible extension would be an opaque blob to carry client attestation information (for ), if desired. The current set is empty, but I suspect we'll need freedom to extend here as this gets used without totally changing the protocol version. If folks are generally supportive of this, it should probably land after , which touches and renames PDAUploadReq to PDAReport.
Both (1) and (2) are external to the protocol. The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report, as is done here. This is done in the change. This is not meant to close the attestation issue. It's meant to give us the mechanics to address it later.
Right you are. What threw me off was the following statement: The "then these extensions are required to be echoed..." makes it sound as if they're not echoed, which they are. I'm happy with this PR modulo fixing this statement.
Change:
Preconnection during the pre-establishment phase with a Local Endpoint specifier, as well as all properties necessary for Protocol Stack selection.  A Remote Endpoint may optionally be specified, to <del> constrain what Connections are accepted.  The Listen() Action returns a Listener object.  Once Listen() has been called, properties added to the Preconnection have no effect on the Listener and the Preconnection can be disposed of or reused. </del> <ins> constrain what Connections are accepted. The Listen() Action returns a Listener object.  Once Listen() has been called, any changes to the Preconnection MUST NOT have any effect on the Listener.  The Preconnection can be disposed of or reused, e.g., to create another Listener. </ins> Listening continues until the global context shuts down, or until the Stop action is performed on the Listener object:

Discussion:
Fixed text in the API draft to allow reusing Preconnections as discussed in . However, changes to the Preconnection MUST NOT have any effect on the Connections or Listeners created beforehand - I think normative language is useful here to really highlight this possible pitfall. I omitted any note on deep copy as that's just a way to implement this.
Great catch, it makes me wonder why we had closed issue ? Thanks for doing this!Thank you - fix achieved with minimal changes ;-)
Change:
A different Captive Portal API URI could be returned in the following cases: <del> Whenever a new Portal URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </del> <ins> Whenever a new Captive Portal API URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </ins> 5.

Discussion:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.
Change:
proxy is notified by its operating system that its socket is no longer usable, it MUST close the request stream.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close <del> the request stream before closing the socket.  Proxies that close </del> <ins> the request stream when closing the socket.  Proxies that close </ins> sockets after a period of inactivity SHOULD NOT use a period lower than two minutes, see Section 4.3 of BEHAVE.

Discussion:
For some kinds of implementations, the action of closing a QUIC stream is not immediate. Do we really want to make this ordering so strong? There's not really any way to enforce it.
That makes sense. I'd like to keep the "MUST close the request stream" but we can remove the ordering requirement or make it a SHOULD.
Either of those options works for me. I can make a PR tomorrow.
Change:
When the decoder receives a header block with a Required Insert Count greater than its own Insert Count, the stream cannot be processed <del> immediately, and is considered "blocked" (see {blocked-decoding}). </del> <ins> immediately, and is considered "blocked" (see blocked-decoding). </ins> The decoder specifies an upper bound on the number of streams which can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting (see

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
unintelligible, as described in Section 1.1 of DPLPMTUD. QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect <del> from off-path injection as specified in RFC8201 and Section 5.2 of </del> <ins> from packet injection as specified in RFC8201 and Section 5.2 of </ins> RFC8085.  This validation SHOULD use the quoted packet supplied in the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of DPLPMTUD).

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
7.1.6. <del> This boolean property specifies, if true, that an application wants this Message to be acknowledged immediately by the receiver.  In case of reliable transmission, this informs the transport protocol on the sender side faster that it can remove the Message from its buffer; therefore this property can be useful for latency-critical applications that maintain tight control over the send buffer (see sending). 7.1.7. </del> This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of the Capacity Profile protocol and path selection property (see prop- cap-profile). <del> The following values are valid for Instantaneous Capacity Profile: </del> <ins> The following values are valid for Transmission Profile: </ins> No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when sending

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.