jiebi/CodeConvo huggingface dataset:
Change:
a lifetime ("lt"), <del> a registration resource location inside the RD ("loc"), </del> <ins> a registration resource location inside the RD ("href"), </ins> optionally a sector ("d")

Discussion:
This executes the renaming of con to base and domain to sector as agreed on in the last meeting. Two follow-up commits create consistency in the ER diagram (which had to be modified anyway for the renaming) and the accompanying text, both internally (describe groups the same way as resources) and within the document (we describe several properties of a group that the ER did not show).
Change:
For webpush scenarios, this would contribute to unnecessary radio communications to maintain the connection on battery-powered devices. <del> Advertising the alternate port (1001) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent. </del> <ins> Advertising the alternate port (WEBPUSH-PORT) allows middleboxes to optimize idle timeouts for connections specific to push scenarios with the expectation that data exchange will be infrequent. </ins> Middleboxes SHOULD comply with REQ-5 in RFC5382 which requires that "the value of the 'established connection idle-timeout' MUST NOT be

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:
4.5. <ins> Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling.  Distinguishing ACK packets is trivial in TCP, but not supported by QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. 4.6. </ins> [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on

Discussion:
...addressing NAME
Middlebox vendors (and others as well) used to TCP want to assume that the smallest packet might be ack packets. This is not true in QUIC, and manageabiity draft may want to say something about it.
Thanks for writing this up!
Change:
a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. <del> 5.9. </del> <ins> 5.10. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is

Discussion:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?
Change:
and 'ietf-tcg-algs.yang' ref-ietf-tcg-algs with prefix 'taa'. Additionally, references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key, <del> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </del> <ins> TPM1.2-Structures, bios-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </ins> 2.1.1.1.

Discussion:
NAME I did what I could in the time remaining. Please check and I think there are only two comments left unaddressed.
Change:
The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the <del> destination CID.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </del> <ins> Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </ins> A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, <del> source and destination UDP ports, destination CID, and a local secret. </del> <ins> source and destination UDP ports, Destination Connection ID field, and a local secret. </ins> 10.

Discussion:
We've been pretty disciplined about using "connection ID", except for the text on flow labels and one mention in the diagram for preferred_address. Of course, the mentions in the flow label text were specifically for the "Destination Connection ID field", so that is what I used there.
"Use of IPv6 Flow-Label and Migration" and the definition of "preferred_address" both reference "CID" without that abbreviation of Connection ID having been defined elsewhere. It's pretty obvious, but the text for IPv6 should probably just write out connection ID in long form.
Change:
sufficient to prevent looping.  In the event of a loop, this results in packets eventually being too small to trigger a response. <del> An endpoint can remember the number of Stateless Reset packets that it has sent and stop generating new Stateless Reset packets once a limit is reached.  Using separate limits for different remote addresses will ensure that Stateless Reset packets can be used to close connections when other peers or connections have exhausted limits. A Stateless Reset packet that is smaller than 41 bytes might be identifiable as a Stateless Reset packet by an observer, depending upon the length of the peer's connection IDs.  Conversely, not sending a Stateless Reset packet in response to a small packet might result in Stateless Reset packets not being useful in detecting cases of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers. </del> <ins> An endpoint can remember the number of Stateless Resets that it has sent and stop generating new Stateless Resets once a limit is reached.  Using separate limits for different remote addresses will ensure that Stateless Resets can be used to close connections when other peers or connections have exhausted limits. A Stateless Reset that is smaller than 41 bytes might be identifiable as a Stateless Reset by an observer, depending upon the length of the peer's connection IDs.  Conversely, not sending a Stateless Reset in response to a small packet might result in Stateless Resets not being useful in detecting cases of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers. </ins> 11.

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
"sendrecv" from RFC4566 MUST be implemented to signal information about media direction. <del> RFC5576 MUST be implemented to signal RTP SSRC values. </del> <ins> RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. </ins> RFC4585 MUST be implemented to signal RTCP based feedback.

Discussion:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.
Change:
"R2.time == R1.time" but "R2.jitter <= R1.jitter", then we say that "R2" _does not follow_ "R1". <del> To prevent replay attacks, it suffices for each aggregator to ensure that each report it consumes follows the previous one it consumed. To prevent the adversary from tampering with the ordering of reports, honest clients incorporate the ordering-sensitive parameters "(time, jitter)" into the AAD for HPKE encryption. Note that this strategy may result in dropping reports that happen to have the same timestamp and jitter value. </del> <ins> To prevent replay attacks, each aggregator ensures that each report it consumes follows the previous one it consumed.  To prevent the adversary from tampering with the ordering of reports, honest clients incorporate the ordering-sensitive parameters "(time, jitter)" into the AAD for HPKE encryption.  Note that this strategy may result in dropping reports that happen to have the same timestamp and jitter value. Aggregators prevent the same report from being used in multiple batches by only consuming valid collect requests, as described in pa- collect. </ins> 8.8.

Discussion:
This partially addresses the problem of preventing inter-batch replay attacks described by NAME in . Along the way, clean up the description of collect requests so that it talks about protocol messages rather than API calls (as NAME suggested).
Similar to , it should not be possible for a share to be included in more than one batch. The timestamp currently gives us some way of ensuring that reports map to at most batch, but not a way of ensuring that reports aren't included two overlapping batch windows. It's not immediately clear if include a single report in two overlapping batch windows is a problem, or if a problem only arises when these windows are disjoint. We should probably clarify what are the inter-batch requirements here and what sort of replay prevention is required.
The aggregators (either the leader or helper) can prevent the collector from getting outputs from overlapping batches by remembering batch intervals. For example, suppose the leader responded successfully to a collect request for time interval . Then suppose that, some time later, the collector requests output shares for , where . The potential privacy violation occurs because the sets of reports in each batch are non-disjoint. To prevent this, the leader might respond to the second request with an error, or it might just include the reports in .
If aggregators are meant to use the report timestamp to protect against replay, then I think it needs to appear in the AEAD-ed message constructed by the client (i.e. ). Otherwise a leader could insert arbitrary timestamps into and trick helpers into exceeding privacy budgets or double counting inputs. Additionally, a batching client could insert arbitrary values into .
I created a PR that addresses this issue partially. What's left to do is allow multiple collect requests over the same batch, as required by the PDA protocol (e.g., Hits). I have an idea for how to do this, I'll follow up with a PR.
Closed by URL
Change:
authorization valid for all orders until the authorization expires. <del> The challenges that the client can fulfill in order to prove possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array entry is an object with parameters required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.  For final authorizations it contains the challenges that were completed. </del> <ins> For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier.  For final authorizations, the challenges that were used.  Each array entry is an object with parameters required to validate the challenge. A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.  For final authorizations it contains the challenges that were completed. </ins> The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  If a domain name contains non-

Discussion:
This pull request includes changes to: Consistently use "header parameter" when referring to JWS header parameters. Insert a missing right curly bracket in a section reference. Use "server-initiated" instead of "administratively initiated" for clarity. Use parallel sentence structure for clarity/readability.
Change:
QUIC or another protocol running over UDP. When sending its UDP proxying request, the client SHALL perform URI <del> template expansion to determine the path and query of its request. </del> <ins> Template expansion to determine the path and query of its request. </ins> target_host supports using DNS names, IPv6 literals and IPv4 <del> literals.  Note that this URI template expansion requires using pct- </del> <ins> literals.  Note that this URI Template expansion requires using pct- </ins> encoding, so for example if the target_host is "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42".

Discussion:
-> a URI Template
but also is it "URI Template" or "URI template"? this seems inconsistent through the document
Change:
2. <ins> This section describes different types of glue that may be found in DNS referral responses.  Note that the type of glue depends on the QNAME.  A particular record can be in-domain glue for one response and sibling glue for another. 2.1. </ins> The following is a simple example of glue records present in the delegating zone "test" for the child zone "foo.test".  The nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both below the delegation point.  They are configured as glue records in the "test" zone: <del> Referral responses from "test" for "foo.test" must include the glue records in the additional section (and set TC=1 if they do not fit): </del> <ins> A referral response from "test" for "foo.test" with in-domain glue looks like this: </ins> <del> 2.1. </del> <ins> 2.2. Sibling glue are glue records that are not contained in the delegated zone itself, but in another delegated zone from the same parent.  In many cases, these are not strictly required for resolution, since the resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling zone.  However, most nameserver implementations today provide them as an optimization to obviate the need for extra traffic from iterative resolvers. Here the delegating zone "test" contains 2 sub-delegations for the subzones "bar.test" and "foo.test": A referral response from "test" for "foo.test" with sibling glue looks like this: 2.3. [missing glue isn't really a type of glue, so we'll need to think about this] </ins> While not common, real life examples of servers that fail to set TC=1 when glue records are available, exist and they do cause resolution

Discussion:
work in progress. please do not merge without review & discussion.
Should we use the naming for Glue from 8499?
"Sibling domain glue" "in-domain glue" and maybe we should define "orphan glue/promoted glue". while we have 8499bis open?
IMO 8499 doesn't have glue definitions that are useful for this draft, so yeah, maybe they should be added to 8499.
Change:
0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before <del> the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </del> <ins> the Initial packet. Note that clients send Initial packets before servers do, servers send Handshake packets before clients do, and only clients send Initial packets with tokens, so the sides of a connection can be generally be confirmed by an on-path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet. </ins> 3.3.

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.
Change:
The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is <del> intended to verify that the server actually speaks for the domain. </del> <ins> intended to verify that the server actually speaks for the domain(s). </ins> Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain

Discussion:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME
Change:
Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length. <del> 4.1. </del> <ins> 5.1. </ins> Long headers take the form described in fig-long.

Discussion:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.
Change:
IANA [SHALL add/has added] the following notes for additional information: <del> The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never </del> <ins> The role of the designature expert is described in [this-RFC]. The designated expert RFC8126 ensures that the specification is publicly available.  An Internet Draft that is posted and never </ins> published or a standard in another standards body, industry <del> consortium, university site, etc. suffices. </del> <ins> consortium, university site, etc. suffices.  The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the cipher suite. </ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the

Discussion:
This change aligns the DE text and adds more info about what the DE does and doesn't do. It also capitalizes "Recommended" so that it's more clear that we're referring to the column. NAME PTAL
LGTM, thanks for unifying the DE language.
Change:
mDNS resolution for name N2 does not complete until after the STUN checks are received. <del> 5. </del> <ins> 6. </ins> The goal of this mechanism is to keep knowledge of private host IP addresses within the ICE agent while continuing to allow the

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
The "security characteristics" MUST indicate the cryptographic <del> algorithms in use (For example: "AES-CBC" or "Null Cipher".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. </del> <ins> algorithms in use (For example: "AES-CBC".)  However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. </ins> The "security characteristics" MUST indicate whether PFS is provided.

Discussion:
Addressing .
From Cullen's 20171106 review: At the end of section 5.5, there is mention of a NULL cipher in an example. I don't think that is allowed and thought is not a problem the way it is mentioned here, perhaps it should be removed from the example.
NAME Version -06, exposed the NULL ciphers at the top level so are you suggested to just delete the part in the parenthetical or the rest of the sentence too: i.e.,: The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI.
Change:
extensions is defined. Protocol extensions supported by the WHIP server MUST be advertised <del> to the WHIP client on the 201 created response to initial HTTP POST request to the WHIP enpoint by inserting one Link header for each extension with the extension "rel" type attribute and the uri for the HTTP resource that will be available for receiving request related to that extension. </del> <ins> to the WHIP client on the 201 Created response to the initial HTTP POST request sent to the WHIP endpoint.  The WHIP endpoint MUST return one Link header for each extension with the extension "rel" type attribute and the URI for the HTTP resource that will be available for receiving requests related to that extension. </ins> <del> Protocol extensions are optionasl for bot WHIP clients and servers. </del> <ins> Protocol extensions are optional for both WHIP clients and servers. </ins> WHIP clients MUST ignore any Link attribute with an unknown "rel" attribute value and WHIP servers MUST not require the usage of any of the extensions.

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.