jiebi/CodeConvo huggingface dataset:
Change:
6.4. <ins> When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender MUST discard all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets (see Section 17.2.2.1 of QUIC- TRANSPORT).  At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is discarded. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). 6.5. </ins> The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow.

Discussion:
Move the "Discarding Keys and Packet State" section up a level and out from underneath the Crypto Handshake Timer. This section in no way references the crypto handshake timer, so there's no reason to put it there. It's possible this should be up-leveled out of loss recovery as well? The preceding "Retry and Version Negotiation" has a similar problem, so I'd like suggestions on where to move that too.
Change:
information faster and more reliably.  Note that, for the foreseeable future, captive portals will still need to implement interception techniques to serve legacy clients, and clients will need to perform <del> probing to detect captive portals. </del> <ins> probing to detect captive portals"; nonetheless, the mechanism provided by this document provides a more reliable and performant way to do so, and is therefore the preferred mechanism for captive-portal detection. </ins> Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages.

Discussion:
Ben suggested: "I was just thinking that if we have a whole sentence about how "you're going to have to do the old thing anyway, though", someone might read that and say "well, if I have to keep doing the old thing, why should I bother with this new thing". So, appending a "; nonetheless, the mechanism provided by this document provides a more reliable and performant way to do so, and is therefore the preferred mechanism for captive-portal detection" or similar is what I had in mind."
Will do, and just submit ('ain't nobody got time for nit PRs :-P)
Maybe de-hyphenate captive-portal
Change:
key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations <del> to mitigate tracking using key configurations. </del> <ins> to mitigate tracking using key configurations.  CONSISTENCY provides an analysis of the options for ensuring the key configurations are consistent between different clients. </ins> 10.

Discussion:
What do we want to do with this draft? Should we dispatch it and find it a home?
Good question. I wonder if secdispatch would be a good place to ask.
Clients should cache server keys for some time. TTL can be supply in a cache-control header of a ohttp-keys response. Should this be mentioned or is it implied?
The document doesn't really define the key configuration acquisition method, so it can't really cover details like caching (or retention). Getting into specifics with HTTP Cache-Control is out of scope. There is discussion of retention periods in , which are relevant and might be worth pointing to. That document has uncertain status, but we might still use an informative reference.
Change:
setting this timer, implementations are cautioned that the new path could have a longer round-trip time than the original.  A value of three times the larger of the current Probe Timeout (PTO) or the <del> initial timeout (that is, kInitialRtt*2) as defined in QUIC-RECOVERY </del> <ins> initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY </ins> is RECOMMENDED.  That is: Note that the endpoint might receive packets containing other frames

Discussion:
1789:Retransmittion Timeout (RTO) as defined in {{QUIC-RECOVERY}} is RECOMMENDED. 2182:(RTO) interval as defined in {{QUIC-RECOVERY}}. 2253:draining state before the packets arrive. If a peer could timeout within an RTO
Also, we have to set a minimum for the path validation timout. Suggest initial timeout(kInitiaRtt2)3 = 600ms. That makes this a design issue.
LG, one suggestion.
Change:
If the stream header indicates a stream type that is not supported by the recipient, the remainder of the stream cannot be consumed as the <del> semantics are unknown.  Recipients of unknown stream types MAY abort reading of the stream with an error code of H3_STREAM_CREATION_ERROR or a reserved error code (http-error-codes), but the recipients MUST NOT consider such streams to be a connection error of any kind. </del> <ins> semantics are unknown.  Recipients of unknown stream types MUST either abort reading of the stream or discard incoming data without further processing.  If reading is aborted, the recipient SHOULD use the H3_STREAM_CREATION_ERROR error code or a reserved error code (http-error-codes).  The recipient MUST NOT consider unknown stream types to be a connection error of any kind. </ins> As certain stream types can affect connection state, a recipient SHOULD NOT discard data from incoming unidirectional streams prior to

Discussion:
NAME observed a seeming conflict in the requirements around unknown unidirectional stream types. Section 9 says: This has two problems. First and editorial, if the type is unknown/unsupported, the presence of frames can't be determined. This should refer to discarding any data, not frames specifically. Second, it appears to disagree with Section 6.2: I think the intent was MUST abort, but MAY pick an error code. Looking at the history of the commits in Section 6.2, it was first MUST abort, then SHOULD use a particular code, then became MAY use the specific code with the prohibition on blowing up the whole connection. The text should clarify the scope of the MAY.
Agree. This change would meet the intent of the text and is editorial. So it the proposal here something like:
I think I'd say "MUST either abort reading of the stream or discard incoming data without further processing. If reading is aborted, the recipient SHOULD use...."
That would work for me too, care to make a PR?
Closed in .
LGTM thank you
Change:
In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number <del> (NUM), more bit (M), and block size exponent (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33 would be shown as </del> <ins> (NUM), more bit (M), and block size (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33 would be shown as </ins> 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128.

Discussion:
URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.
Change:
2.2.2. <del> When receiving a packet on a RTP stream where EKT was negotiated, the following steps are applied for each received packet. </del> <ins> When receiving a packet on a RTP stream, the following steps are applied for each received packet. </ins> The final byte is checked to determine which EKT format is in use. When an SRTP or SRTCP packet contains a ShortEKTField, the

Discussion:
Inbound Processing When receiving a packet on a RTP stream where EKT was negotiated, the following steps are applied for each received packet.
I don't think you can ever receive non EKT packets on a flow with EKT negotiated. That is to say know from the SDP when you get a SRTP packet if it is EKT or not
Use of EKT must be negotiated in signalling on a per session basis. In the case of PERC, all multiplexed flows must use EKT. For WebRTC, that should also be true, unless a determination can be made based on the payload type. That actually raises a question. How are PERC endpoints supposed to construct the SDP for PERC that indicates use of DTLS? Is that going to be in Adam's draft? PERC endpoints are always required to initiate the DTLS association.
Framework and Signaling draft should sum up the usage of this.
More reason to delay framework until we know we've covered everything.
Framework is not getting published anytime soon . We have time :)
Change:
application/link-format+cbor and application/link-format+json, respectively, as they are defined in I-D.ietf-core-links-json. ] <del> At the same location where URI discovery happens, a user who wants to debug interoperability issues can ask for additional information that might be available about the server using generic resource discovery techniques.  That information would typically be stored in an implementation information link (as described in I-D.bormann-t2trg- rel-impl): </del> <ins> A user can introspect the server for implementation information to ease debugging by using the URI discovery address as described in RFC6690 Section 4.  Information about the used software would typically be stored in an implementation information link (as described in I-D.bormann-t2trg-rel-impl): </ins> Note that depending on the particular server's architecture, such a link could be anchored at the server's root, at the discovery site

Discussion:
This adds an example of how impl-info can be used to obtain implemetation software and version information. Closes: URL
But why would you want to do the latter, if not for the former or for some privacy-intrusive application? (Well, OK, netcraft style surveys. But these are not the motivation for documenting this, either.) Grüße, Carsten
The text in the RD spec suggests that debugging is needed and that debugging is possible thanks to the rel-impl relation. That is a bit strong: I can debug without the rel-impl relation. cabo schreef op 2018-01-31 17:27:
I was referring to generic use of .well-known/core as opposed to the formally limited interface ( described in the URI Discovery section. The pull request will be updated to address both concerns; thanks for the review.
Closed after immediate comments were addressed; it appears we're deep enough into the discussion of impl-info details that the direction is good.
There is a lot of confusing info in the first 4 lines. Debugging is not the problem, getting information about the implementation is. What are generic resource discovery techniques? We do have one specification called RD., and /.well-known/core The example is terse; Nice to know what the link means or is supposed to provide Thanks for the text; it helps to focus.
Change:
A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that <del> it forces concentrated centralization amongst those participants.{ {?CENTRALIZATION=I-D.nottingham-avoiding-internet-centralization}} discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what candidate participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the system used to control the Web's trust model. </del> <ins> it forces concentrated centralization amongst those participants. CENTRALIZATION discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what candidate participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the system used to control the Web's trust model. </ins> Alternatively, Privacy Pass deployments might mitigate this problem through implementation.  For example, rather than centralize the role

Discussion:
cc NAME
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL
Change:
Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a <del> PADDING frame to arbitrarily increase the size of packets. Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, both during the handshake and for connection migration.  Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </del> <ins> PADDING frame to arbitrarily increase the size of packets.  Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, during the handshake (see Sections 8.1 and 14.1 of QUIC) and for path validation after connection migration (see Section 8.2 of QUIC) as well as for Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see Section 14.3 of QUIC). Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </ins> 6.

Discussion:
“Padding is used by QUIC to ensure” - please add a sentence that DPLPMTUD is another reason why you might expect QUIC Padding of specific packets after connection establishment, and refer to section in QUIC transport - or people may have a surprise when they suddenly see big probe packets in their logs:-)
I thought that this is what the sentence is about? The whole sentence says: "Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, ..." We can add a reference to the right section in the transport draft but sure we need another sentence? However, your point about being surprised to see big packets probably rather belongs into manageability...?
Ah sorry: I was trying to highlight that there are two places where I think QUIC might be expected to use padding... in the initial connection ... to verify the path supports the minimum size, and later whenever DPLPMTUD is invoked, to probe to check for a larger size. Two section refs would likely be useful. ... Yes, it could be mentioned in manageability - since often QUIC packets might be rather uniform in size with occasional DLPMTUD probes?
I created a PR to add references to the respective sections in the QUIC transport draft. Explaining in detail what padding is used for internally in QUIC wasn't really the point here. However, it's probably correct that the sentence should not just omit one usage (PLDMTUD) and reference probably don't hurt. Do we need still something for manageability? Or is that, at least partially, already addressed by ?
Looks good
Change:
WT_STREAMS_BLOCKED frames contain the following field: <del> Maximum Streams: A variable-length integer indicating the maximum number of streams allowed at the time the frame was sent.  This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^(62-1). </del> <ins> A variable-length integer indicating the maximum number of streams allowed at the time the frame was sent.  This value cannot exceed 2 , as it is not possible to encode stream IDs larger than 2 -1. </ins> 5.11.

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
Initial packet number space doubles the length of the timeout in the Handshake packet number space. <del> The time length of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout. </del> <ins> The total length of time over which consecutive PTOs expire is limited by the idle timeout. </ins> The probe timer MUST NOT be set if the time threshold (time- threshold) loss detection timer is set.  The time threshold loss

Discussion:
This PR is also a good spot to comment on my accidental commit() to master. I can make any changes to that in this PR.
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
Some suggestions only.One nit, but LGTM.
Change:
If present, a single "a=setup" line is parsed as specified in RFC4145, Section 4, and the setup value is stored. <del> If the "m=" proto value indicates use of RTP, as decribed in the </del> <ins> If the "m=" proto value indicates use of RTP, as described in the </ins> sec.profile-names section above, the following attribute lines MUST be processed:

Discussion:
This is all strictly editorial and I think if either of you give it a quick scan, you can just merge it
LGTM - will merge
Change:
An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml <del> [9].  This tool has been used effectively in several Working Groups, </del> <ins> [6].  This tool has been used effectively in several Working Groups, </ins> though it requires server infrastructure. Additionally, clear reporting about the changes that were included in

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be <del> conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </del> <ins> conveyed in any number of ways, including: as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document

Discussion:
The list in sec 3.2 didn't render properly. Also fix Pete's surname which got garbled for some reason.
Change:
are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS.  Future supported groups MUST define the value of this column.  A Standards Track document RFC8126 is <del> required to register an entry with the value "Yes". </del> <ins> REQUIRED to register an entry with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> IANA [SHALL add/has added] the following note:

Discussion:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .
Change:
(*) indicates changes to the wire protocol. <ins> draft-11 Editorial changes based on AD comments Add support for DTLS Address address ambiguity in cert expiry </ins> draft-10 Address superficial comments

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.