jiebi/CodeConvo huggingface dataset:
Change:
support initiating and receiving new streams using existing connections. <del> 2. The Transport Services architecture is based on the survey of Services Provided by IETF Transport Protocols and Congestion Control Mechanisms RFC8095, and the distilled minimal set of the features offered by transport protocols I-D.ietf-taps-minset.  These documents identified common features and patterns across all transport protocols developed thus far in the IETF. Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this architecture also considers the impact of transport security protocols on the feature-set exposed by transport services I-D.ietf-taps-transport-security. One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance (referred to as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols.  For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent. However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. 2.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. The goal of the Transport Services architecture is to redefine the

Discussion:
Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.
Change:
10. <del> A remote entity (Verifier or Relying Party) may need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </del> <ins> A Verifier or Relying Party may need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </ins> Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch

Discussion:
Looked at all uses of "entity" in the doc to be sure it wasn't referring to Verifier or RP which are roles and found a few issues in the Freshness section.
Change:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no <del> effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </del> <ins> effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </ins> The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute

Discussion:
LGTM
lgtm
In URL 'certificates' is a set, and the PeerConnection selects which certificate to use. The SDP should have one 'a=fingerprint' line per certificate, and that is not reflected in the JSEP draft AFAICU.
Prague: One a=fingerprint line per cert, but we can go down to a single cert one DTLS has been established. The DTLS cert has to match one of the supplied a=fingerprints. (NAME correct as necessary)
PR added for allowing multiples. Processing rules go in the TBD applying section
Change:
helps mitigate this issue. Each EKT cipher specifies a value T that is the maximum number of <del> times a given key can be used.  An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey.  In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in dtls-srtp-extensions. </del> <ins> times a given key can be used.  An endpoint MUST NOT encrypt more than T different Full EKT Field using the same EKTKey.  In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in dtls-srtp-extensions. </ins> The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
response.  The content type of each request is "application/octet- stream".  We assume that some transport layer security protocol (e.g., TLS or QUIC) is used between each pair of parties and that the <del> server is always authenticated. </del> <ins> server is authenticated. </ins> [TODO: Decide how to provide mutual authentication in leader-to- helper and collector-to-leader connections.  One option is to use

Discussion:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information.

So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.
Change:
Instance as administratively provisioned at and distributed by the DODAG root. <del> MOPex: Extended MOP: This document extends the MOP values over a bigger range.  This extension of MOP is called MOPex. </del> <ins> MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex]. </ins> Capabilities: Additional features or capabilities which might possibly be optional that are supported by the node.

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: <del> There is no ServerHello extension that the server is required to echo back. </del> <ins> The compress_certificate extension is a unidirectional indication; no corresponding response extension is needed. </ins> 4.

Discussion:
Update reference.
Almost, but I think I can accept my own suggestions so I'll just do that and merge.
Change:
The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. <del> 4.5.2. </del> <ins> 4.4.2. </ins> Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
the tag.  If this check fails, it MUST abort with error "invalidHmac". <del> Next, it first checks that the sequence of Transition messages corresponds to the ReportShare sequence of the AggregateInitReq.  If any message appears out of order or is missing, or a transition has an unrecognized nonce, then the leader MUST abort with error </del> <ins> Next, it checks that the sequence of Transition messages corresponds to the ReportShare sequence of the AggregateInitReq.  If any message appears out of order or is missing, or a transition has an unrecognized nonce, then the leader MUST abort with error </ins> "unrecognizedMessage". Next, for each Transition, the leader proceeds as described in prep-

Discussion:
While implementing upload today, I also noticed some inconsistencies between the handling of reports in the leader during the upload protocol and the helper
Change:
Limited RTT measurement is possible by passive observation of QUIC traffic; see sec-rtt.  No passive measurement of loss is possible <del> with the present wire image.  Extremely limited observation of upstream congestion may be possible via the observation of CE markings on ECN-enabled QUIC traffic. </del> <ins> with the present wire image.  Limited observation of upstream congestion may be possible via the observation of CE markings on ECN- enabled QUIC traffic. On-path devices can also make measurements of RTT, loss and other performance metrics when information is carried in an additional network-layer packet header (Section 6 of I-D.ietf-tsvwg-transport- encrypt describes use of operations, administration and management (OAM) information).  Using network-layer approaches also has the advantage that common observation and analysis tools can be consistently used by multiple transport protocols, however, these techniques are often limited to measurements within one or multiple cooperating domains. </ins> 4.2.

Discussion:
Refers to quicwg. This also addresses /extremely limited/ ECN visibility (limited for sure, but we don't need to say "extremely"). Fixed multiple definitions of RTT Refered to metrics, etc for encrypted traffic wrt network-layer measurement via a REF.
Thanks for the suggestions from Ian and Mirjay, they were of course incorporated.
Change:
of the attacker is to learn private information about the inner ClientHello, such as the true SNI value. <del> 10.10.1. </del> <ins> 10.11.1. </ins> This attack uses the client's reaction to an incorrect certificate as an oracle.  The attacker intercepts a legitimate ClientHello and

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38 <del> for the definition of the latter. </del> <ins> for the definition of the latter.  Language tag and writing direction information for unadorned text strings are intended to be obtained from context; if that context needs to be saved or forwarded with a Concise Problem Details data item, "base-lang" and "base-rtl" can be used for that.  If no such (explicitly saved or implicit) context information is available, unadorned text is interpreted with language-tag "en" and writing-direction "false" (ltr). </ins> The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.

Discussion:
Capture the discussion in the 2022-06-08 interim and .
Comment by NAME : I have a hard time motivating why this can be unadorned CBOR text string, given that these two fields are always human-readable text. Maybe we need to add a default, i.e. that when text used, that is to be interpreted as English language is used.
(w/ TF:) making "foo" a shorthand for 38(["en", "foo", false]) makes sense in the Anglo-American dominated world we live in. Details (en? en-US?) need to be discussed though.
I wouldn't go down the rabbit hole of also picking the locale. Too much stress I'm happy with the minimum required to satisfy the rule, i.e., "en".
In we decided to go with the following: use context if available fall back to english Now, similar to , should we have a (and ) keys for when the CPD is stored/forwarded and therefore the context is lost?
LGTM
Change:
The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver <del> that has been added to the PeerConnection.  This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </del> <ins> that has been added to the PeerConnection, excluding any stopped RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique

Discussion:
Originally raised by Magnus: This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . I am bit surprised to see "recycled" on a list of things that may occur in generating an initial offer? Can that really occur?
check this - prob editorial
Change:
between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. <del> If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for the query and is providing the best answer it could get.  This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </del> <ins> A DNS API server is allowed to answer queries with any valid DNS response.  For example, a valid DNS response might have the TC (truncation) bit set in the DNS header to indicate that the server was not able to retrieve a full answer for the query but is providing the best answer it could get.  A DNS API server can reply to queries with an HTTP error for queries that it cannot fulfill.  In this same example, a DNS API server could use an HTTP error instead of a non- error response that has the TC bit set. </ins> Many extensions to DNS, using RFC6891, have been defined over the years.  Extensions that are specific to the choice of transport, such

Discussion:
Attempt to deal with . I'm not convinced that this is much better than the current text, but it might help others.
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.
Change:
intermediaries. If an intermediary processes distinct HTTP requests that refer to the <del> same flow identifier in their respective "Datagram-Flow-Id" header fields, it MUST ensure that those requests are routed to the same backend. </del> <ins> same flow ID in their respective "Datagram-Flow-Id" header fields, it MUST ensure that those requests are routed to the same backend. </ins> 8.

Discussion:
This somewhat of an experiment. While trying to address I got distracted by the document's use of the "flow identifier" term. The document likes to compare "flow identifiers" with QUIC streams, which is fine. But QUIC makes the distinction between streams and stream IDs; the ID is a property of the stream but it isn't the only one, and sometimes it helps to talk about the stream in other contexts. This change tries to channel a similar editorial style. It replaces: "flow identifiers" with "flows" when talking about a logical entitiy "flow identifiers" with "flow IDs" when talking about the wire format, encoding, examples etc. This could be a change too far but I figured it would be a good discussion starter.
The draft doesn't do this. It relies on the QUIC varint encoding for non-negativity in DATAGRAM frames but could contain a negative value. Let's be clear in the spec.
Definitely agree, could you write a PR please?
I will.
fixed in URL
Thanks!
Change:
In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain <del> the length of the packet number, encoded as an unsigned two-bit integer that is one less than the length of the Packet Number </del> <ins> the length of the Packet Number field, encoded as an unsigned two- bit integer that is one less than the length of the Packet Number </ins> field in bytes.  That is, the length of the Packet Number field is the value of this field plus one.  These bits are protected using header protection; see Section 5.4 of QUIC-TLS.

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
An IP proxying request that does not conform to these restrictions is malformed (see H2 and H3). <ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: </ins> 4.4. The IP proxy SHALL indicate a successful response by replying with

Discussion:
Our cousin, CONNECT-UDP, has simple examples about how the requests and responses look in HTTP/1.1, 2 and 3. I appreciate the appendix has complicated examples. Would it be worth providing simple examples in Section 4, or at least forward referencing to them so people can get a feel?
That would be nice, if someone's willing to volunteer to do the editorial work of writing that PR. In other words, I'll happily review and merge it, but I don't have time to write it personally.
there's 5 authors on the draft, maybe one of the other 4 can spare the 10 minutes it would take?
Simple enough to add =)
Thanks for writing this!
Change:
the measurement being taken.  For instance, to measure the time the user took performing a given task the proof might demonstrate that the value reported was within a certain range (e.g., 0-60 seconds). <del> By contrast, to report which of a set of N options the user select, the report might contain N integers and the proof would demonstrate that N-1 were 0 and the other was 1. </del> <ins> By contrast, to report which of a set of "N" options the user select, the report might contain "N" integers and the proof would demonstrate that "N-1" were "0" and the other was "1". </ins> It is important to recognize that "validity" is distinct from "correctness".  For instance, the user might have spent 30s on a task

Discussion:
Based on .
NAME can you please rebase? Some of the changes we improved on in now appear here.
Rebased.