jiebi/CodeConvo huggingface dataset:
Code change:
If endpoint receives an unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type <del> MP_CONNECTION_ERROR and close the connection. </del> <ins> TRANSPORT_PARAMETER_ERROR (specified in Section 20.1 of QUIC- TRANSPORT) and close the connection. </ins> This extension does not change the definition of any transport parameter defined in Section 18.2. of QUIC-TRANSPORT.

Related discussion:
text: Fix issue
In section 3, we have However, the error code does not exist (anymore), and I'm not sure we need such a specific error code anyway. Why not raising a in such case?
It's reasonable to use TRANSPORTPARAMETERERROR. Submitted PR for this issue.
Code change:
Therefore it needs to respond to the request without waiting for a packet from the target.  However, if the target_host is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP <del> request.  If errors occur during this process (for example, a DNS resolution failure), the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy-Status" header field PROXY- STATUS. </del> <ins> request.  If errors occur during this process, the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy- Status" header field PROXY-STATUS (for example, if DNS resolution returns an error, the proxy can use the dns_error Proxy Error Type from PROXY-STATUS). </ins> UDP proxies can use connected UDP sockets if their operating system supports them, as that allows the UDP proxy to rely on the kernel to

Related discussion:
text: I also want to point an issue due to this stance. The fact that we are not explicit and discuss the expectations and realities of different IP versions we have interesting failure cases due to this text from Section 3.1: “However, if the target_host is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP request.” No where in the follow paragraphs in this section do it discuss the slight issue that a DNS resolution can return only an AAAA record and the MASQUE server may only support IPv4. What is the error response? Should this be a proxy-status response. I would not there are currently no response for “IP version not supported”.
These concerns apply equally to TCP proxying via HTTP. We should strive to provide parity to how CONNECT treats these matters. HTTP semantics don't say anything
+1 to Lucas' meta-comment about striving for parity with CONNECT There is no such thing as a "unsupported IP version" DNS failure. Let's take an example where the client wants to CONNECT-UDP via the UDP proxy to the target . This particular host is configured such that querying AAAA will get a valid address, and querying A will yield a "no answer no error" DNS result. Let's assume that in this example the UDP proxy is IPv4-only. In that scenario, the UDP proxy will only query A (because it doesn't know what AAAA is) and it will get "no result no answer" so it will send
NAME in light of the previous comments, can you clarify what you think is missing from the document please?
First of all, I think that just answering lets do like Connect is a poor answer. There are benefits to alignment, but also one should ask if one are preventing useful functionality. In this case I think there are a relevant difference between what could be answered depending on how one implement stuff. Your suggest road says that for a IPv4 only proxy with a DNS name that has AAAA record but no A record the answer is: a) There is no answer For a node that would query both the answer could actually be: b) There is host, but I can't reach it as I don't support the right IP version, try another proxy. Sure, limiting ourselves to a) is easy, but is it the most useful for the protocol?
Disagree it's a poor answer.
Code change:
Therefore it needs to respond to the request without waiting for a packet from the target.  However, if the target_host is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP <del> request.  If errors occur during this process (for example, a DNS resolution failure), the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy-Status" header field PROXY- STATUS. </del> <ins> request.  If errors occur during this process, the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy- Status" header field PROXY-STATUS (for example, if DNS resolution returns an error, the proxy can use the dns_error Proxy Error Type from PROXY-STATUS). </ins> UDP proxies can use connected UDP sockets if their operating system supports them, as that allows the UDP proxy to rely on the kernel to

Related discussion:
text: An HTTP proxy that inplements CONNECT for UDP is likely going to implement CONNECT for TCP. How to treat name resolution for both of these has to be consistent. The Proxy-Status header field is the appropriate way to signal such failures. Any text more complicated than what we have now, should be pursued in a separate document IMO. Not added at this late stage. It would be straightforward to form up a document like "DNS considerations for HTTP proxying" that is additive to the specifications we have.
I agree: Proxy-Status is the right place for this discussion, and CONNECT-UDP already recommends Proxy-Status. Also, as a technical matter, this is not how dual-stack connectivity works. As noted above, an IPv4-only UDP client will never issue a AAAA query for a destination hostname.
I agree with what Lucas and Ben said above. Let's move this discussion to an extension draft.
I agree that this discussion probably deserves to be in an extension draft. As is stands today, a DNS failure as described in this thread can just as easily result in a destination-unreachable / connection-closed error for the CONNECT-UDP stream, and an extension to provide detailed information as to why seems like the natural path forward.
Proxy status is absolutely the right thing to do here. The proxy-status is what we are already doing in production for CONNECT and CONNECT-UDP. The current text seems entirely appropriate for this: The only thing I could see saying further is to mention the error parameter, like this: I do not think we need any extension draft for this. This is very straightforward, and doesn't need to say much.
Thanks Tommy, I think that's a useful clarification. I wrote up PR based on your proposal to make this clearer
Ok, I am fine with this resolution.
Thank you for confirming Magnus!
Code change:
[4] https://about.gitlab.com/ <del> [5] https://trustee.ietf.org/license-for-open-source- repositories.html [6] https://github.com/dontcallmedom/github-notify-ml </del> <ins> [5] https://github.com/dontcallmedom/github-notify-ml </ins>

Related discussion:
text: I was tempted to remove the entire section on administrative policies, though left it as is. NAME what do you think?
Yeah, I figured it best to start small. Let me know if you need anything else before merging!
NAME Interesting that the circle CI build ran on the merge, but not the PR. I didn't see any build failures reported before it merged, but I just got the email reporting a missed reference. Maybe there are some tweaks you need to apply over there as owner of the org.
Yeah, I'll fix it. Thanks for letting me know!
I was thinking of being a little more aggressive about removing some of the text, with matching PRs for the other work, but this works.
Code change:
prioritization. Note that this property is not a per-message override of the <del> connection Priority - see conn-priority.  The Priority properties may </del> <ins> Connection Priority - see conn-priority.  The Priority properties may </ins> interact, but can be used independently and be realized by different mechanisms; see priority-in-taps.

Related discussion:
text: This changes the use of the term "entanglement" as discussed in , and moves some text around in this section for better clarity and less repetition. Also, addressing , it introduces a framer as an optional parameter to the Clone call.
NAME I incorporated all of your suggestions, thanks!
This is not fully clear from section 5.4., however, if connections in a group are each QUIC streams, I think it should be possible to use different framers on each stream. So it might be okay that a framers is copied when clone is called but changing a framer on one connection should not change the framer on the other connection in a group...?
Also an related editorial comment (that could be addressed in the same PR eventually): this section on groups only at the very end has a paragraph starting with "Note that calling Clone() can result in on-the-wire signaling..." which kind of explains that groups are supposed to be used for multistream protocol but can also be mapped to separate connection if the protocol doesn't not support multiplexing of stream on one connection. I think this information should be added at the very beginning of this section.
Actually, now looking at the framer section, I guess you would rather like to already set the new framer before you clone a connection...?
I agree with everything you say here; about your last suggestion, maybe a framer should be an optional argument of the clone call?
I don’t actually understand the difference between a connection in a Connection Group and an “entangled connection” ? Both terms are used in API, but in different ways (possibly by different authors) - do we really really need the word “entangled”?? if we do we need, can we define and explain this.
I think that having the word is good as it indicates a deeper relationship than mere "grouping". Just based on terms, I'd (correctly) imagine that I can define priorities between members of a group, and that they somehow belong together... as in: Close with a common call, etc. ... but I don't think that I would expect, just from this term, that changing a property on one of them affects all the others. Hence the phrasing: "The connections within a group are 'entangled' with each other". However, I agree that in most other places, we should talk about "groups" instead.
Code change:
prioritization. Note that this property is not a per-message override of the <del> connection Priority - see conn-priority.  The Priority properties may </del> <ins> Connection Priority - see conn-priority.  The Priority properties may </ins> interact, but can be used independently and be realized by different mechanisms; see priority-in-taps.

Related discussion:
text: I can try to fix this.
Sounds good - we should add that explanation upfront in the definitions then also?
[Yes, I think so.] EDIT: no, now I don't think so anymore. (see )
I have addressed this in PR . Note that the text interchangeably talked about both Connections and Connection Properties as being "entangled". I have now written this such that the term "entanglement" applies to Connection Properties only, whereas Connections in a group are, well, members of the same Connection Group.
Looks good to me.
Code change:
an HTTP Datagram.  This prevents infinite loops in the presence of routing loops, and matches the choices in IPsec IPSEC. <ins> IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since CONNECT-IP conveys IP packets in HTTP Datagrams and those can in turn be sent in QUIC DATAGRAM frames which cannot be fragmented DGRAM, the MTU of a CONNECT-IP link can be limited by the MTU of the QUIC connection that CONNECT-IP is operating over.  This can lead to situations where the IPv6 minimum link MTU is violated. CONNECT-IP endpoints that support IPv6 MUST ensure that the CONNECT- IP tunnel link MTU is at least 1280 (i.e., that they can send HTTP Datagrams with payloads of at least 1280 bytes).  This can be accomplished using various techniques: if HTTP intermediaries are not in use, both CONNECT-IP endpoints can pad the QUIC INITIAL packets of the underlying QUIC connection that CONNECT-IP is running over. if HTTP intermediaries are in use, CONNECT-IP endpoints can enter in an out of band agreement with the intermediaries to ensure that endpoints and intermediaries pad QUIC INITIAL packets. CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that one of the two previous techniques is sufficient, they MUST use this method. </ins> Endpoints MAY implement additional filtering policies on the IP packets they forward.

Related discussion:
text: I get that, but since the complexity is added by intermediaries we just need to make it clear that the intermediary needs to not be silly
One part is to detect if the link is capable of 1232 bytes, however, if not, we also not to provide more guidance what to do. I think there are two options: either close the connection or use quic streams instead of data datagrams.
Code change:
The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE <del> in the packet's IP header.  ECN Counts are only present when the ACK </del> <ins> in the packet's IP header.  ECN counts are only present when the ACK </ins> frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format. <del> The three ECN Counts are: </del> <ins> The ECN count fields are: </ins> A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of

Related discussion:
text: This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!
Code change:
Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner-trust. </del> <ins> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </ins> 8.

Related discussion:
text: TLS authentication is sufficient for establishing trust in the various entities before sending them privacy sensitive data. TLS is also widely supported today and attestation between servers is not. Most likely TLS will be the mechanism. This PR adds mention to in addition to attestation.
Addresses
says that the way for an Endorser to trust and Verifier is to use attestation. While I won't categorically say this should never be done, it seems like this is overly complex and a somewhat misuse of attestation. I think of the Verifier as a service like a web site, not an implementation like a TEE, so TLS or similar, not attestations, seems like the more efficient and conventional way to do this. I think attestation is associated with actual HW and SW, for example the Dell server, Intel CPU and Web stack used to run the service. The operator of a Verifier gets to change those around without having to tell the people using the service. On the other hand, if a Verification Service changes owners, say from Chinese to American, then Endorser concerned about confidential stuff in the Endorsements really wants to know. I also think that Verifier Owner should not be lumped in with Endorser. The Verifier Owner is very likely to be tightly coupled organizationally with the Verifier, where the Endorser is not likely to be.
PR addresses this well enough.
Reviewing the trust relationships described in the architecture document got me thinking about sharpening a distinction between device attestation (e.g., EAT for phone) and service authenticity (e.g. HTTPS for a web site): Device Attestation Focus is on the implementation, the HW and SW The legal entity of interest is the device manufacturer The claims are about the HW and the SW, not the device owner Example: a mobile phone (not its owner/user) Example: integrity of a remote device Service Authenticity Focus is on the provider of the service, not the HW or SW The legal entity of interest is the service provider There is no equivalent of claims, but if there was they would be about the business or person operating the service Example: a web site Example: an email provider (IMAP service) Service providers (e.g., web sites) use whatever HW and SW they want to use. As a user of the service we don’t care what HW and SW they select.
Code change:
Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner-trust. </del> <ins> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </ins> 8.

Related discussion:
text: We trust the service provider to pick good HW and SW and to configure and operate it correctly. They might change the HW and the SW and as a user we won’t know. For example we trust Bank of Xxx to operate their banking web site correctly with little concern for their HW. This is why attestation of the HW and SW is not so useful to the user of a service. Users of mobile phones and IoT devices are not trustworthy to pick secure HW and SW. They are not professionals like the people running web sites. There is little accountability against them if they pick bad SW and HW. Therefor we want attestation for these usage scenarios. This is why EAT, FIDO and Android Attestation exist. I don’t think the line between device attestation and service authenticity is completely black and white. In some use cases attestation may be bent to provide some service authenticity. But I don’t think it makes sense to add attestation to the millions of web sites out there, add support for it to browsers and make attestation an extra layer of security for web browsing. I think it is fine for a service provider to use attestation inside their service to monitor integrity and such of the HW and SW providing the service. But usually that won’t be manifest outside the service. It could be awkward for the user to the service to have to re evaluate the service every time the service provider changes HW. Another way to look at this is from a certification / regulatory view. If the thing you're looking at is a candidate for implementation certification such as Common Criteria, FIPS, FIDO certification, then it probably lines up with device attestation. On the other hand, if the thing your are looking at lines up with regulation (e.g., banking regulation, GDPR,...) and to some degree OWASP, then it probably lines up with service authenticity. I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS"
In the last editors session, the editor's rough consensus was that https does not provide the authenticity but it provides a secure channel. Instead, authenticity is checked via successful authentication rooted in identity documents (I hope I captured appropriately, please bash).
Code change:
Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner-trust. </del> <ins> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </ins> 8.

Related discussion:
text: Taking that into account, how does this effect this issue? Looking at the last paragraph, "Remote attestation procedures are not a replacement for secure authentication, they are based on secure authentication." might be missing vital parts. Does anything need to be added or modified here?
Note that is INCORRECTLY referenced here. Is the resolution of a different issue about HTTPS vs Attestation.
I think comments from NAME do need to be taken into account when the text to address this issue is written. My text in opening the issue is not intended as the text to resolve the issue. Probably the text that resolves the issue needs to refer to "HTTPS plus the web certificate infrastructure that includes public CA's and browsers and/or private CA's used in B-to-B..." or such.
I think the RATS architecture document should probably have text that describes when attestation is applicable and when it is not, for example saying something like “attestation is not a replacement or augmentation for HTTPS/TLS" The design team disagrees with this. Every authentication (including HTTPS) can be said in terms of attestation. It is the verifier that allows the decoupling of the RP to know the expected state of the Attester.
Code change:
Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error. <del> If the Path Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object should register for incoming traffic on all of the network interfaces or paths that conform to the Path Selection Properties. The set of available paths can change over time, so the implementation should monitor network path changes and register and de-register the Listener across all usable paths.  When using multiple paths, the Listener is generally expected to use the same port for listening on each. If the Protocol Selection Properties allow multiple protocols to be used for listening, and the implementation supports it, the Listener object should register across the eligble protocols for each path. This means that inbound Connections delivered by the implementation may have heterogeneous protocol stacks. </del> <ins> If the Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object should register for incoming traffic on all of the network interfaces or paths that conform to the Properties.  The set of available paths can change over time, so the implementation should monitor network path changes and register and de-register the Listener across all usable paths.  When using multiple paths, the Listener is generally expected to use the same port for listening on each. If the Selection Properties allow multiple protocols to be used for listening, and the implementation supports it, the Listener object should register across the eligble protocols for each path.  This means that inbound Connections delivered by the implementation may have heterogeneous protocol stacks. </ins> 4.8.1.

Related discussion:
text: Connection properties really are about configuring something, but I still say that being able to use them as early input is good. I agree that the implementation isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME I just pushed a commit that updates the selection and connection properties text, removing "connection" almost everywhere, but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation, and "In the remainder of this document, we only refer to Selection Properties because they are the more typical case." Frankly I'm not sure this is better... but it does remove most of the "selection and connection" double mentions that you pointed out.
Fixed up branch building and resolved merge conflicts. I'll merge this in later today before the posting deadline.
Cool thanks! Sorry if I messed something up
As discussed in
Thank you for updating this – looks good! just needs s/send-params/msg-properties/ and merging