jiebi/CodeConvo huggingface dataset:
Change:
"Report.encrypted_input_shares" is equal to the index of the aggregator in the task's "aggregator_endpoints" to which the AggregateInitializeReq is being sent.  The "agg_param" field is an <del> opaque, VDAF-specific aggregation parameter.  The "job_id" parameter contains the leader's chosen AggregationJobID. </del> <ins> opaque, VDAF-specific aggregation parameter provided during a collection flow.  The "job_id" parameter contains the leader's chosen AggregationJobID. [[OPEN ISSUE: Check that this handling of "agg_param" is appropriate when the definition of Poplar is done.]] </ins> Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with its

Discussion:
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
LGTM -- thanks!
Change:
interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares <del> the message flows for these two mechanisms with (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13. </del> <ins> the message flows for these two mechanisms with (D)TLS 1.3 RFC8446 I- D.ietf-tls-dtls13. </ins> These two mechanisms can be complementary.  A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients.  Both mechanisms require a trusted relationship between the Front-End and Back-End - the delegated credential can be used in place of a certificate <del> private key, and the remote key signing case is effectively a signing oracle for TLS connections using that certificate. </del> <ins> private key. </ins> Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Management Environment (ACME)

Discussion:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.
Change:
is desired.  Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC <del> applications are encouraged to fail over to TCP if early packets do </del> <ins> applications are encouraged to fall back to TCP if early packets do </ins> not arrive at their destination QUIC-APPLICABILITY, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec-udp-1312). Admitting a few packets allows the QUIC endpoint to determine that

Discussion:
Per Al Morton's opsdir review, review the use of these three terms and correct where appropriate.
Change:
not meaningful in the JSEP context and MAY be discarded once they have been checked. <ins> The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to use "ice-mismatch" to indicate mismatches between "c=" and the candidate lines; because JSEP always uses ICE, "ice-mismatch" is not useful in this context. </ins> TODO The remaining lines are processed as follows: <del> The "c=" line MUST be parsed and stored. </del> [OPEN ISSUE: For example, because session-level bandwidth is ambiguous when multiple media streams are present, a "b=" line at session level is not useful and its value SHOULD be ignored.

Discussion:
NAME is this OK? NAME
lgtm with the one comment above
Ignored is the wrong word to use here. The value is not used is true but ignored is just simply not true.
Hmm.... We're not checking it and not doing anything with it. I'm happy to use another word, but I'm going to need you to suggest one. , Cullen Jennings EMAIL wrote:
NAME please r+ if you are happy. NAME please merge if you are happy.
I really don't care but it like 1 of the 3 things I raised got fixed
I see I missed the trickle thing. What else is there? , Cullen Jennings EMAIL wrote:
Around line 2216 I had another change "SHOULD be ignored" to "is not used". I think we are running into the limitations of using github for review here.
Indeed, I think I missed it. , Cullen Jennings EMAIL wrote:
NAME I think this is ready to merge if you are still happy.
LGTM
lgtm with minor change
When JSEP recommends that lines are ignored (absent some syntax validation), it violates a rule in RFC 5245 regarding mismatch processing. 5245 requires that the values for port and IP address in and correspond to a candidate that appears in the media section. Consensus in Dallas was to prohibit checking of the value in against and , which requires an explicit mention in the draft, since this is different to what 5245 says.
The sole point of mismatch processing is to allow applications to see if some SBC messed with their addresses: If the agent is not proceeding with ICE because there were a=candidate attributes, but none that matched the default destination of the media stream, the agent MUST include an a=ice- mismatch attribute in its answer. Not proceeding with ICE isn't an option here, and this is somewhat problematic with trickle ice (at least the initial 0.0.0.0 candidate), so I think ignoring makes sense.
Change:
GitHub is a service operated at https://github.com/ [5].  GitHub provides centralized storage for git repositories.  GitHub is freely <del> accessible on the open Internet, albeit currently only via IPv4. </del> <ins> accessible on the open Internet. </ins> <del> GitHub provides a simplified and integrated interface to not only git, but also provides basic user management, an issue tracker, associated wikis, project hosting, and other features. </del> <ins> GitHub provides a simplified and integrated interface to git, and also provides basic user management, an issue tracker, associated wikis, project hosting, and other features. </ins> There are a large number of projects at GitHub and a very large community of contributors.  One way in which some IETF Working Groups have benefited is through increased numbers of reviews and associated <del> issues, along with other improvements that come from broader participation by facilitating those in the community to participate. </del> <ins> issues, along with other improvements that come from facilitating participation by a broader community. </ins> 1.3.

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination <del> Connection ID is non- compliant. </del> <ins> Connection ID is unroutable. </ins> Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server

Discussion:
and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Thanks, this is a lot easier to read for me.
Change:
offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </del> <ins> The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </ins> 4.1.2.

Discussion:
...14
LGTM
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed
Change:
e.g., via the controller plane described in I-D.ietf-detnet-data- plane-framework.  When replication is configure, the same app-flow data will be sent over multiple outgoing DetNet member flows using <del> forwarding sub-layer LSPs.  The same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet. </del> <ins> forwarding sub-layer LSPs.  An S-Label value MUST be configured per outgoing member flow.  The same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet. </ins> 4.2.2.2.

Discussion:
Clarifying S-Label procedures (i.e., allowing S-Label value per outgoing member flow after PRF).
Change:
leaders must be at least as capable as helpers, where helpers are generally required to: <del> Support the collect protocol, which includes validating and </del> <ins> Support the aggregate sub-protocol, which includes validating and </ins> aggregating reports; and Publish and manage an HPKE configuration that can be used for the

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to <del> include values for "end_of_early_data" and "missing_extension". </del> <ins> include values for "end_of_early_data", "missing_extension", and "certificate_required". </ins> TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this

Discussion:
and fix also not needed comma
:+1: was about to fix this too. Change was introduced by NAME in f6f752f9af24f99241ba98510cfb1dd758bf4bf9 (included with draft 16).
Hi, I have update the change !
Change:
An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be <del> retained.  Parameters that are not being changed changed SHOULD NOT be included in an update.  Adding parameters that have not changed </del> <ins> retained.  Parameters that are not being changed SHOULD NOT be included in an update.  Adding parameters that have not changed </ins> increases the size of the message but does not have any other implications.  Parameters MUST be included as query parameters in an update operation as in registration.

Discussion:
This PR fixes a simple typo. Side question: I found a number of lines in the markdown document that have spaces before the newline character. Would a PR removing those also be of interest?
Thanks! Re your side question: So I'm not the only person annoyed by trailing spaces :-) I went ahead and fixed this (one command in Emacs :-), including re-aligning a markdown table.
Change:
3. <del> For consistency amongst TLS registries, IANA has prepended "TLS" to the following registries: Application-Layer Protocol Negotiation (ALPN) Protocol IDs RFC7301, ExtensionType Values, Heartbeat Message Types RFC6520, and Heartbeat Modes RFC6520. IANA [SHALL update/has updated] the reference for these four registries to also refer to this document.  The remainder of this document will use the registry names with the "TLS" prefix. 4. Many of the TLS-related IANA registries had the registration procedure "IETF Consensus", which was changed to "IETF Review" by RFC8126.  To align with the new terminology, IANA has updated the following registries to "IETF Review": TLS Authorization Data Formats TLS Supplemental Data Formats (SupplementalDataType) This is not a universal change, as some registries originally defined with "IETF Consensus" are undergoing other changes either as a result of this document or RFC8422. IANA [SHALL update/has updated] the reference for these two registries to also refer to this document. 5. </del> The instructions in this document update the Recommended column, originally added in RFC8447 to add a third value, "D", indicating that a value is "Discouraged".  The permitted values are:

Discussion:
Updated introduction and recommended column section. Deleted some irrelevant sections.
Changed from obsolete to update.
Obsoleting RFC 8447 means duplicating a lot of text and making changes to it which makes the document have awkward wording and makes the changes difficult to follow. I think it would be clearer if it were an update and just listed the changes. see Extension Types PR
At IETF 115, there was general agreement that this document could be an update as opposed to an obsolete to make it easier on IANA.
These are nits.
Change:
parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA RFC7518, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be <del> stripped before the values are Base64url-encoded. </del> <ins> stripped before the values are base64url-encoded. </ins> 7.2.

Discussion:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)
Change:
Protocol header field value, but future documents MAY define parameters.  Receivers MUST ignore unknown parameters. <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </ins> 4.4. This document defines the DATAGRAM capsule type (see iana-types for

Discussion:
The HTTP WG is working on a style guide, see URL In line with the style, the reference to structured fields is updated in because it's less contentious. What remains here is probably more so. First, move the consideration for intermediaries to the bottom of the section. It doesn't seem a leading item to me. Then we start the section with a focus on defining the field itself. The ABNF is probably the bit we'll disagree with. It seems in trying to be specific on the Item type, you've written out the the subcomponents of the ABNF. This is something that is being discussed in the HTTP WG list. Personally I don't like being overly specific in the ABNF because it could be misconstrued as something that is SF-like but not really SF. As far as a generic SF parser goes, it will only validate that the thing is an Item and it will be up to higher layers to apply additional constraints on that. Parameters can always appear with an Item on the wire, whether an application allows that or not is a different matter. Restating ABNF makes this topic more thorny.
Change:
value includes the content type and padding added in TLS 1.3 (that is, the complete length of TLSInnerPlaintext).  Padding added as part of encryption, such as that added by a block cipher, is not included <del> in this count. </del> <ins> in this count (see expansion). </ins> An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3

Discussion:
The idea of this change is to try to constrain how much padding a sender can add. This is done by calculating the size of a record with maximum plaintext and minimum padding. No other record can exceed this size, though smaller packets can pad to reach this size. I was going to include a formula, then realized that the simple answer is best: pad to the record size limit, then pad to get to a multiple of the block size as normal. Most implementations will be OK because they don't bother with the first step.
Change:
user is behind a VPN that masks their IP address.  Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented <del> systems such as Tor. </del> <ins> systems such as Tor.  See I-D.ietf-rtcweb-ip-handling for additional information. </ins> 4.3.

Discussion:
Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.
Change:
QUIC senders use both ack information and timeouts to detect lost packets, and this section provides a description of these algorithms. <del> Estimating the network round-trip time (RTT) is critical to these algorithms and is described first. </del> If a packet is lost, the QUIC transport needs to recover from that loss, such as by retransmitting the data, sending an updated frame,

Discussion:
Explicitly state that round trip time is abbreviated as RTT
In the recovery draft, RTT is briefly spelled out in section 5 but is used in several earlier sections. SRTT and PTO are not explained at all, it seems. TLP is spelled out. RTO has a section of its own but it referenced before that. The recovery doc cannot be a tutorial on transmission theory, but it would be helpful to list the key acronyms and possibly reference an RFC with more details. There are already sections summarising key variables in pseudocode. There are references at the end, but the reader would have to go through them all.
Yes, thanks for the note. I'm planning to do a cleanup of that doc soon.
I fixed defined RTT earlier in .
Change:
section is the algorithm defining which of these options to try, when, and in what order. <ins> During Candidate Gathering, an implementation first excludes all protocols and paths that match a Prohibit or do not match all Require properties.  Then, the implementation will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </ins> 4.1. The step of gathering candidates involves identifying which paths,

Discussion:
In the , people found the normative language in too restrictive and agreed with the original suggestion in . Therefore, this PR moves the selection algorithm text to the implementation draft and removes some normative language in the interface draft. We still want to provide consistency to applications when possible, so there's a sentence in the implementation draft on this now as well.
LGTM modulo the suggestion from NAME which I would accept as-is Great with one minor knit.
Change:
B to C, passings can only be along edges that can be reached from B along the graph, until B is the end of a different passing. <del> The passings starts at the root node, defined as the URI from which the document is obtained. </del> <ins> The passings starts at the root node, usually defined as the URI from which the document is obtained. </ins> For better understanding, think of the structured information model as a sort of tree spanning from the root node, with the oddity that

Discussion:
Closes: URL In the comments there's the question of whether we need that properties of literals that are literals themselves can have properties again. Right now it does no harm, but no good either; I have no use case that's not completely contrived, and the number of properties we can round-trip through RDF is quite limited anyway.
I think we should pick the information model variation where literals can't have arbitrary outgoing statements, but only properties (that happen to be serialized just like other statements). Allowing nested statements from literals is kinda nice conceptually, but it is hard to explain (as it requires all the "blank node" explanations over again) is impractical in conversions is hard to visualize correctly Realistically, literals can have a type (if they're string-form; for everything else conversion can be guided by tags) or a language (which AIU is also a type these days when considering LTR/RTL). We might also see things like content format (for embedded representations), but if we want to carry them over to RDF, we can't do the literal attributes anyway, and I think we don't need to (because we now also have 's tags for content formats and can thus easily tag things inside CBOR). Are there any arguments we should have in an issue beforehand? Otherwise I'd start a pull request at my next CoRAL session.
While writing this up, I stumbled over which CBOR data model to pick for equivalence. Making literals identical to each other if they are identical in the CBOR generic data model seems the right thing to do (as opposed to going into the extended data model), as it is easier and stable. I think that we (or applications) can still define additional equivalences later on.