jiebi/CodeConvo huggingface dataset:
Change:
An Action creates an Object: <ins> An Action creates an array of Objects: </ins> An Action is performed on an Object: An Object sends an Event:

Discussion:
section 6.3 (Rendezvous) has the following line: PreconnectionBinding := Preconnection.Resolve() If i read the text correctly, I'd propose to change this to Preconnection<> := Preconnection.Resolve()
Agreed, not sure what a is...
Agreed; the text would need to change to compensate as well. NAME is the on an array of preconnections? I don't think we have a notation for this yet ( are event params), but we probably should.
Agree with the change. are new objects derived from the initial by a process like ICE. E.g., once the resolve call has done a STUN exchange to find the external address of a NAT you're behind, you'll get back an object that represents that external address.
lgtm
Change:
3.2.2. Once the cloud registrar has determined pledge ownership, the cloud <del> registrar may redirect the pledge to the owner registrar in order to </del> <ins> registrar MAY redirect the pledge to the owner registrar in order to </ins> complete bootstrap.  Ownership registration will require the owner to register their local domain.  The mechanism by which pledge owners register their domain with the cloud registrar is out-of-scope of

Discussion:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".
Change:
maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets. <del> TODO: explain how TLS_NULL_WITH_NULL_NULL is not actually a cipher at all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext </del> 5.2.3. All encrypted TLS records can be padded to inflate the size of the

Discussion:
LGTM
This was always a hack. We should just remove mention of this as a "cipher suite" and just talk about certain messages being encrypted and others not.
If issue is done, then I think the only cleartext messages left would be the 3 hello messages: ClientHello, ServerHello, & HelloRetryRequest. TLSPlaintext could then just be renamed to TLSHelloRecord, which would make the distinction between cleartext and encrypted records relatively easy.
I agree that this psuedo-cipher-suite should be removed. It is confusing. Some implementations may work in a way where they implement some TLSNULLNULLWITHNULL_... cipher suite, but that's an implementation detail. Other implementations, particularly implementations that don't do renegotiation, likely won't work like that.
Change:
on-path devices that a flow has ended is that packets are no longer observed.  Stateful devices on path such as NATs and firewalls must therefore use idle timeouts to determine when to drop state for QUIC <del> flows. </del> <ins> flows, see further section sec-stateful. </ins> 3.6.

Discussion:
But how long...?
For discussion: should the manageability draft advise that idle timeouts should be longer for flows inferred/detected to be QUIC flows? I think the answer here is "it depends": for NATs, yes, state at the edge is not all that scarce anymore. For firewalls? Maybe not so much. Are there other applications to consider here, and is there any generalized advice this document could give? If so, is there any generalized advice for how long the timeout should be?
PR is an attempt to address this issue but doesn't provide much concrete guidance...
Change:
the CBOR and JSON representation of link format.  The RD resource paths /rd, /rd-lookup, and /rd-group are example values.  The server in this example also indicates that it is capable of providing <del> observation on lookup results. </del> <ins> observation on resource lookups. </ins> [ The RFC editor is asked to replace these and later occurrences of TBD64 and TBD504 with the numeric ID values assigned by IANA to

Discussion:
Text changes after it seems that empty 2.05+Content-Format observed representations work. Example updated because it seems fitting for the RD to announce that capability. (Not that the indication changes anything about the possibility, but clients might not even try otherwise). Closes: URL NAME would this shortened text still satisfy your concerns?
For the example "obs" on rd-lookup/res is sufficient.
Hi Chris, thanks for all the work. We are making progress. I commented on 2 of the pull requests (typo and suggestion). Text is suggested for the commit on identification; I did not like the "debugging" annotation at all. Once everything is committed, I hope to go through it all again with today's knowledge. NAME I think Chris's text is terse but correct; can you close the issue, or suggest small changes? Thanks, peter chrysn schreef op 2018-01-31 19:25:
ad "obs in /rd-lookup/res only": I don't see why the server should, but it works just as well, so why argue, updated.
It is an example. It shows that not all needs to be observed. chrysn schreef op 2018-02-01 12:21:
Change:
Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay. <del> The third stage completes the process by enabling validation of the negotiation version as though the new version were disabled. </del> <ins> The third stage completes the process by enabling authentication of the negotiated version with the assumption that the new version is fully available. </ins> The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse.

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.
Change:
the connection ID, but MUST use a different connection ID when doing so. <ins> Note that if the sender retires a Connection ID that is still used by in-flight packets, it may receive ACK_MP frames referencing the retired Connection ID.  If the sender stops tracking sent packets with retired Connection ID, these would be spuriously marked as lost. To avoid such performance issue without keeping retired Connection ID state, an endpoint should first stop sending packets with the to-be- retired Connection ID, then wait for all in-flight packets to be either acknowledged or marked as lost, and finally retire the Connection ID. </ins> 4.2.3. QUIC-TRANSPORT allows for closing of connections if they stay idle

Discussion:
It might be possible to be in a state where a sender retires a DCID that was used by still in-flight packets. Hence, it is possible for the sender to receive a ACKMP frame referencing the retired DCID. Depending on the situation: The sender can keep a way to track the sent packet with the retired DCID sequence number, allowing proper acknowledgement of the packets. The sender drops all the state related to the DCID, hence marking the in-flight packets as being lost and ignoring ACKMP frames having a retired DCID sequence number. While this should not affect interoperability, it might be worthwhile to add a sentence or two to mention the possible performance issue in such situation.
We could add some text to . Can you propose a PR NAME ?
Change:
4.5. <ins> 5. </ins> WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header field with a Bearer token as specified in RFC6750 section 2.1.  WHIP clients MUST

Discussion:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases.

Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested
Change:
the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT. <del> 2.5. </del> <ins> 2.6. </ins> The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet

Discussion:
The manageability document should illustrate all the various packet sequences in a handshake, preferably with pretty pictures.
Now the transport draft has these illustrations as well. However, I think we should still at them in manageability as well. Actually I would like to try the SVG format here. Anybody in for that?
The handshake illustrations here should only concern themselves with the wire image, unlike those in the transport draft, but yes we should derive them from the transport draft. Happy to do these in ASCII as well as SVG.
The problem with examples is that they might be typical, but they rarely capture the breadth of options well. Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed. For instance, put PADDING first.
Change:
the helper's encrypted aggregate share for the batch interval by sending an "AggregateShareReq" to the helper as described in aggregate-share-request.  The leader then computes its own aggregate <del> share by aggregating all of the prepared output shares that fall within the batch interval. </del> <ins> share "agg_share" by aggregating all of the prepared output shares that fall within the batch interval.  Finally, it encrypts it under the collector's HPKE public key as follows: where "pk" is the collector's public key. </ins> When both aggregators' shares are successfully obtained, the leader responds to subsequent HTTP GET requests to the collect job's URI with HTTP status 200 OK and a body consisting of a "CollectResp": <del> "shares" is a vector of "EncryptedAggregateShare"s, as described in aggregate-share-request, except that for the leader's share, the "task_id" and "batch_interval" used to encrypt the "AggregateShare" are obtained from the "CollectReq". </del> <ins> The "encrypted_agg_shares" field is the vector of encrypted aggregate shares.  They MUST appear in the same order as the aggregator endpoints list of the task parameters. </ins> If obtaining aggregate shares fails, then the leader responds to subsequent HTTP GET requests to the collect job URI with an HTTP

Discussion:
When constructing HPKE contexts, we now include both sender and recipient roles, and the application label also includes the PPM version. I used here because we recently submitted draft-01 of and so the next submitted draft, which would include this change, will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non-controversial we can get a head-start on bringing those changes into main.
Fixed, thank you! I also rewrote the relevant paragraph to acknowledge that there's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself. Further, I recall NAME pointing out to me that should this draft get adopted by the WG, we'll reset to something like , so is the more appropriate application label.
There's one more instance of that needs to be changed to . Otherwise, LGTM.
Change:
An indexed header field with post-base index representation identifies an entry in the dynamic table with an absolute index <del> greater than or equal to the Base. </del> <ins> greater than or equal to the value of the Base. </ins> This representation starts with the '0001' 4-bit pattern.  This is followed by the post-base index (post-base) of the matching header

Discussion:
This change has been suggested by afrind at URL on the basis that the Base is a count, and comparing an index to a count feels awkward.
Change:
The setup protocol for WebRTC data channels described in I-D.ietf- rtcweb-data-protocol MUST be supported. <ins> Note: DTLS-SRTP as defined in RFC5764 section 6.7.1 defines the interaction between DTLS and ICE ( RFC5245).  The effect of this specification is that all ICE candidate pairs associated with a single component are part of the same DTLS association.  Thus, there will only be one DTLS handshake even if there are multiple valid candidate pairs. </ins> WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification RFC5764, section 5.1.2.  All application layer protocol payloads over

Discussion:
LGTM with comment above.
I think we should just refer people to 5763, S 6.7.1: Interactive Connectivity Establishment (ICE), as specified in [RFC5245], provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream. Specifically, I think we should say: Note: DTLS-SRTP as defined in defines how DTLS interacts with ICE in Section 6.7.1. As indicated therein, implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs.
Rephrased according to Justin's suggestion.
Change:
political opinions in relation to the 2019 Hong Kong protests Victor- 2019.  See also discon. <del> 4.2.4. </del> <ins> 4.2.5. </ins> DPI (deep packet inspection) technically is any kind of packet analysis beyond IP address and port number and has become

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!
Change:
4.6. <del> TODO 4.7. </del> Importance: Base This event is used to track progress through QUIC's complex handshake

Discussion:
Connection retried was never properly specced. The main reason is that a retried connection is completely separate from the original connection attempt, except for the value, and as such is usually logged in a separate file / separate context from the original connection qlog data. Current qlog deployments either have other ways of correlating retried connections with the original attempts, or don't need to do this. Either way, there is no tangible need for at this time.
I don't think that's correct. You also take your Connection IDs with you to the new connection. quic-go logs it to the same file, as it is the same connection attempt. I don't see value in though.
Change:
Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this in profile PR], as specified in I-D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in </del> <ins> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in </ins> Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs]

Discussion:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm
Change:
STREAMS_BLOCKED frames contain the following fields: <del> A variable-length integer indicating the stream limit at the time the frame was sent.  Stream IDs cannot exceed 2^62-1, as it is not possible to encode stream IDs larger than this value.  Receipt of a frame that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. </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^60, as it is not possible to encode stream IDs larger than 2^62-1.  Receipt of a frame that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. </ins> 19.15.

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
STREAMS_BLOCKED frames contain the following fields: <del> A variable-length integer indicating the stream limit at the time the frame was sent.  Stream IDs cannot exceed 2^62-1, as it is not possible to encode stream IDs larger than this value.  Receipt of a frame that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. </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^60, as it is not possible to encode stream IDs larger than 2^62-1.  Receipt of a frame that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. </ins> 19.15.

Discussion:
This is based on and is targeted for that. Careful. I did a bit of language tweaking to the 260 limits on the MAX_STREAMS frame to make it a little more useful. The text there was a little old.
Change:
parameters "initial_max_stream_data_bidi_local".  An HTTP/3 server SHOULD send non-zero values for the QUIC transport parameters "initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". <del> It is recommended that "initial_max_bidi_streams" be no smaller than </del> <ins> It is RECOMMENDED that "initial_max_bidi_streams" be no smaller than </ins> 100, so as to not unnecessarily limit parallelism. HTTP/3 does not use server-initiated bidirectional streams; clients

Discussion:
IIUC, RFC 2119 keywords used in RFC 7540 need to be converted to uppercase words in HTTP/3, because HTTP/3 invokes RFC 8174.
That was never an interoperability requirement, just a suggestion. So I think that this should be reverted. If it isn't, using the active voice might be better.

That was never an interoperability requirement, just a suggestion. So I think that this should be reverted. Originally posted by NAME in URL Look at a better way to phrase this guidance, while still retaining the guidance. (Note this text has also been touched by other PRs in the meantime.)