jiebi/CodeConvo huggingface dataset:
Change:
and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" <del> value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del> <ins> value MUST be set to "webrtc-datachannel" as specified in I-D.ietf- mmusic-sctp-sdp, Section 4.1. </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an <del> "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in I-D.ietf-rtcweb-data-protocol. [OPEN ISSUE: the -01 of this document is missing this information.] </del> <ins> "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST

Discussion:
Did not carefully review but looks fine to me
lgtm
Section 5.2.1 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. [OPEN ISSUE: the -01 of this document is missing this information.]
According to -07, a=sctpmap is no more, and replaced with a=fmtp, plus a=sctp-port. We still need to reference the appropriate string for the m= line.
Change:
instance, the collector might authenticate themselves by logging into a website that has some trust relationship with the leader.)] <del> [TODO: @chris-wood suggested we specify APIs for producing and consuming each of the messages in the protocol.  Specific PDA protocols would implement this API.] </del> *Error handling.* In this section, we will use the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various error conditions.  The behavior is

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:
Each setting option indicates a setting that will be applied by the sender. <del> One CSM MUST be sent by both endpoints at the start of the connection.  Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. </del> <ins> One CSM MUST be sent by each endpoint at the start of the connection. Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. </ins> Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if

Discussion:
Partially addresses
It is analogous, because the structure of the subregistry is slightly different (additional column). We can add a sentence that the value of the additional column does not influence the choice of the policy. Good point. OK, “update” is not the right word them. Good point. It was smeared all over the document, and then we collected it in an appendix. I don’t think anyone would have a strong opposition against making it a mainline section. Should we?
In general, I prefer to separate out unrelated issues (editorial or not) to simplify tracking/closing: Regarding: There are at least three similar cases of "both endpoints" which would need to be corrected together.
NAME - Regarding Ben's comment (which you seem to concur with ...): 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." The text actually updates RFC7252 to address all cases. I don't see how it effectively removes UDP support since the text is additive. For example: This step from [RFC7252]: If does not equal the request’s destination UDP port, include a Uri-Port Option and let that option’s value be . is updated to: If does not equal the request’s destination UDP port or TCP port, include a Uri-Port Option and let that option’s value be .
NAME - I do not feel strongly about moving Appendix A - but I'm open to suggestions. It's hard to find the right place in the flow - perhaps before/after Section 6?
This issue is partially addressed by - which I'm merging now since I'm on leave for the next two weeks. The other potential editorial changes are pending responses from NAME
Change:
13.2.5. An endpoint measures the delays intentionally introduced between when <del> an ack-eliciting packet is received and the corresponding acknowledgment is sent.  The endpoint encodes this delay for the largest acknowledged packet in the Ack Delay field of an ACK frame (see frame-ack).  This allows the receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.  A packet might be held in the OS kernel or elsewhere on the host before being processed.  An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame. </del> <ins> the packet with the largest packet number is received and an acknowledgment is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK frame (see frame-ack).  This allows the receiver of the ACK to adjust for any intentional delays, which is important for getting a better estimate of the path RTT when acknowledgments are delayed.  A packet might be held in the OS kernel or elsewhere on the host before being processed.  An endpoint MUST NOT include delays that it does not control when populating the Ack Delay field in an ACK frame. </ins> 13.2.6.

Discussion:
From Timo Völker's comment on the QUIC mailing list. There might be a better way to state this, but I think this is more accurate.
Change:
All new entries must define the Label Name, Label, and XML Type but the CBOR labels SHOULD be left empty as CBOR will use the string <del> encoding for any new labels.  The ID fields contains the EXI schemaID of the first Schema which includes this label or is empty if this label was not intended for use with EXI.  The Note field SHOULD </del> <ins> encoding for any new labels.  The ID fields contains the EXI schemaId value of the first Schema which includes this label or is empty if this label was not intended for use with EXI.  The Note field SHOULD </ins> contain information about where to find out more information about this label.

Discussion:
Make sure the way we use schemaID match how it is defined in EXI. ( See email from Christian G - Oct 10, 2016 )
Change:
For certain types of issuance protocols, this model separates attestation and redemption contexts.  However, Issuance protocols that require the Issuer to learn information about the Origin, such <del> as that which is described in [rate-limited], are not appropriate since they could link attestation and redemption contexts through the </del> <ins> as that which is described in RATE-LIMITED, are not appropriate since they could link attestation and redemption contexts through the </ins> Origin name. 4.3.

Discussion:
cc NAME
draft-ietf-privacypass-architecture says in section 3.2: Is that correct? Isn't the 'token-key' in draft-ietf-privacypass-auth-scheme providing the pub key? Or do I misunderstand something here?
Oops, yep, good catch! We'll fix this.
Change:
1.4.3. <del> A wildcard "*" (wildcard) in the expression "[*]" selects all children of a node and in the expression "..[*]" selects all </del> <ins> A wildcard "*" (wildcard-selector) in the expression "[*]" selects all children of a node and in the expression "..[*]" selects all </ins> descendants of a node. An array slice "start:end:step" (slice) selects a series of elements

Discussion:
(Once completed)
Thanks. is not yet closed; completing this is meant to do that. The triple dot bug was already fixed here in . For me it doesn't matter where additional comments are made. I wonder whether we should finish this round (fixing bugs) before doing a grand renaming. I also would like some feedback on the names proposed...
well, finishing this round before going on is fine.
I think if we agree this we should merge it. Next step could be the great renaming, possibly with some further testing of the grammar. In particular, we should throw collections of JSONPath queries we can find at it. If you have pointers, I could prepare that.
NAME Two sources of queries: URL URL
E.g.,
I propose a slightly more compact naming of ABNF of - and -segment, which should be more consistent between them two. is well known from LaTeX and means or there.
above is wrong (and so it is in the current spec). It needs to read ... to not allow triple dot ( :-)
NAME Wouldn't dotdot-wildcard etc. be less cryptic?
Here are some quibbles with the current ABNF (prior to PR being merged) which we can sort out after The Great Renaming:
Yes, yes. See. Fixed in I like the way this looks like now. Maybe I don't understand; can you elaborate? Fixed this (and following) in Removed in To be fixed in overall overhaul, next Yes! To be fixed in overall overhaul, next To be fixed in overall overhaul, next Fixed in Discuss this in its own issue, I'd say. Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths. To stay normalized, we don't allow random other ones.
Of course ... I'm quite dispassionate here.
Please see my proposal in
With merged, we still have the expression cleanup the separate issue (enhancement) whether should be allowed, to mean
My remaining points are covered by PRs , , and .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind?

The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic. But that can be a new issue.
Indentation of : number of lines such indented
(And it doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this. ... or do we need two selectors here (Ch.2.61) child-longhand = "[" S selector 1(S "," S selector) S "]" given that '1' means 'at least one'.
Change:
6. <ins> COSE supports two different MAC structures.  COSE_MAC is used when the key needs to be explicitly identified.  The structure supports the use of recipient structures to allow for random content encryption keys to be used.  COSE_MAC0 is used when the a recipient structure is not needed because the key to be used is implicitly known. 6.1. </ins> In this section we describe the structure and methods to be used when doing MAC authentication in COSE.  This document allows for the use of all of the same classes of recipient algorithms as are allowed for

Discussion:
Everybody but me wants a MAC w/o recipients.
There also needs to be an equivalent no-recipient signature version. Thanks.
That string does not even parse.
Should the kid attribute be a binary value rather than a string value?
No arguments that binary should not be the only type for this, some questions that binary is useful based on Jose experience. Definite arguement that binary is required. Doing two types is probably a bad idea.
Change:
This document models the result of applying a query to the argument as a nodelist (a list of nodes). <del> So nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values. Member names and members (name/value pairs) cannot be selected.  So </del> <ins> Nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values.  Member names and members (name/value pairs) cannot be selected.  Thus, </ins> member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not.

Discussion:
Signed-off-by: Tim Bray Nothing fancy here, just like the title says.
LGTM, thanks.
Change:
Endpoint must be configured with a group IP address and a port. Calling "Initiate" on a UDP Multicast Receive Connection causes an <del> immediate InitiateError.  This is an unsupported operation. </del> <ins> immediate EstablishmentError.  This is an unsupported operation. </ins> Calling "InitiateWithSend" on a UDP Multicast Receive Connection <del> causes an immediate InitiateError.  This is an unsupported </del> <ins> causes an immediate EstablishmentError.  This is an unsupported </ins> operation. A UDP Multicast Receive Connection is ready once the system has received traffic for the appropriate group and port. <del> UDP Multicast Receive Connections generate an InitiateError indicating that joining a multicast group failed if Initiate is </del> <ins> UDP Multicast Receive Connections generate an EstablishmentError indicating that joining a multicast group failed if "Initiate" is </ins> called. <ins> The only ConnectionError generated by a UDP Multicast Receive Connection is in response to an "Abort" call. </ins> LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from peers, and issues a multicast host join.  If a Remote Endpoint

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!
Change:
The Enforcement Device component restricts the network access of User Equipment according to site-specific policy.  Typically User <del> Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal </del> <ins> Equipment is permitted access to a small number of services (according to the policies of the network provider) and is denied general network access until it satisfies the Captive Portal </ins> Conditions. The Enforcement Device component:

Discussion:
There was some confusion about how network access is constrained for when the user equipment hasn't satisfied the captive portal conditions. Mention that it's up to the provider's policies.
Raised during review. Is it allowed by definition (i.e. within the walled garden) Is it more nuanced? Is it just up to the use-case?
Eric suggests in reply to my suggestions: This would be up to the network operator, I suppose -- they define the extent of the walled garden. The only hosts that must be reachable are any necessary to perform the workflows related to gaining access. The document mentions those in a few places. In section 2.4, the document states: Typically User Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. Perhaps we could add some language indicating that this isn't intended to be a normative requirement -- the restrictions placed by the captive portal depend on its use-case. EV> you may add "(.g., local communication)" after "small number of services" ? I propose we do this.
NAME replied with: Let's do that.
Change:
address as well as source and destination port.  Therefore there can be at most one active paths/connection ID per 4-tuple. <del> The path management specified in section 9 of QUIC-TRANSPORT fulfills </del> <ins> The path management specified in Section 9 of QUIC-TRANSPORT fulfills </ins> multiple goals: it directs a peer to switch sending through a new preferred path, and it allows the peer to release resources associated with the old path.  Multipath requires several changes to

Discussion:
Fix issue
I went ahead and replaced the references to RFC9000 by QUIC-TRANSPORT, and RFC9001 by QUIC-TLS. I have checked that this produced the expected XML V3.
RFC9000 is cited massively in the draft. It would be helpful to indicate to the reader where to look by indicating the section. Some change examples are provided below: and so on.
Side comment -- please see issue about the use of XML2RFC v3 syntax for links. We can do some of that, but not necessarily everywhere. We do expect that readers are familiar with QUIC V1. If we want to say "we are just in line with QUIC V1", then a global reference to RFC 9000 should suffice. If we want to say "please read this text in QUIC V1, we don't want to replicate here", then yes, we should refer to the specific section.
Thanks, Christian. That's the intent.
The draft is using old style references, such as "section 9 of {{RFC9000}}". Version 3 of XML2RFC defines a structure way to do that, such as: , which can be expressed in recent versions of Markdown as . The new style references don't change the text version much, but in the HTML rendering they generate direct references to the target section, which is nice for the readers.
Sorry, that's my fault because of my local build system. Will fix this for the next revision...
With the fixed references, it works now...
Change:
Frame types that were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (iana-frames).  These frame <del> types MUST NOT be sent, and receipt MAY be treated as an error of type H3_FRAME_UNEXPECTED. </del> <ins> types MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. </ins> 8.

Discussion:
We currently say: This text has two failings: It doesn't specify whether the error is a stream error or a connection error In , it was argued that this violation is easily detected, and perhaps warrants a "MUST error" instead of a "MAY error"
+1 to both changes from my perspective.
This sounds like a design issue. Since this spins off from URL and URL I'm going to assume from past discussion that there is sufficient interest in discussing this.
MUST respond with a connection error SGTM. Frames are hop-by-hop (compared to HTTP messages being end-to-end), therefore we can enforce this.
Thanks, NAME This had shades of the tunneling discussion before, and I wasn't sure on which side of that fence you'd land.
NAME Thank you for checking. As stated above, I think we can be strict regarding HTTP frames (especially the types), even though I tend to think that we need to be lax about HTTP messages (and how they are terminated).
Change:
implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous use of multiple addresses), such implementations will need to either actively retrieve the client's current address or addresses when they are relevant or explicitly accept that the original address might change. </ins> 10. 10.1.

Discussion:
Separately from this, I note that Security Considerations is becoming more of a jumbled bag of waving at various concerns. Some organization and expanded text around each topic might be warranted.
Can you add a sub-heading(##) for each of these considerations, like in the transport draft? Originally posted by NAME in URL
Seems mostly right. Though I would prefer something that simply highlighted the fact that a remote address is not expected to be stable over the lifetime of a connection. Therefore, decisions that use an address as input need to either keep up to date, or accept the consequences of not doing so. I would also point out that this is true even if migration is disabled.The text looks great. I really appreciate the fact that we have a recommendation on what IP address we should associate with logging (and address-based authentication).