jiebi/CodeConvo huggingface dataset:
Change:
4.3. <ins> QUIC streams enable ordered and reliable delivery.  Though it is possible for an implementation to provide options that use streams for partial reliability or out-of-order delivery, most implementations will assume that data is reliably delivered in order. Under this assumption, an endpoint that receives stream data might not make forward progress until data that is contiguous with the start of a stream is available.  In particular, a receiver might withhold flow control credit until contiguous data is delivered to the application; see Section 2.2 of QUIC.  To support this receive logic, an endpoint will send stream data until it is acknowledged, ensuring that data at the start of the stream is sent and acknowledged first. An endpoint that uses a different sending behavior and does not negotiate that change with its peer might encounter performance issues or deadlocks. 4.4. </ins> Flow control provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on

Discussion:
Beware those who want to do something else.
Isn't this already covered by the next section on "Flow Control Deadlocks"? If not, what's missing? And can we just add a sentence or two there?
Though the specification does not insist upon it, most implementations will assume that stream data is reliably delivered in order. This means that senders will send until every byte is delivered or they decide to reset the stream (possibly based on STOP_SENDING). And it means that receivers won't make data available until a contiguous span of bytes starting at the last unread offset are available. Implementations might act differently, but variations from this behaviour would need to be agreed by both endpoints.
NAME can you propose text?
Change:
6. <del> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  Instead, the same port number is used as would be used for the same application over TCP.  In the case of HTTP the expectation is that port 443 is used, which has already been registered for "http protocol over TLS/SSL".  However, QUIC-HTTP also specifies the use of Alt-Svc for HTTP/QUIC discovery which allows the server to use and announce a different port number. </del> In general, port numbers serves two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the

Discussion:
Both documents provide limited guidance on use of ports, however, there was an open question if the applicability statement should maybe say more and e.g. also talk about ALPN.
pending consensus on use of ALPN in -transport
We already have consensus to require ALPN. Unless you meant to refer to URL In that case, yes, you might want to explain how this works for HTTP/3 specifically. That is, the HTTP/3 ALPN refers to QUICv1. For now. We have apparently reserved the right to revise that when we define QUICv2. If you start to explain the controversial aspects of this (does ALPN refer to the layer or the stack as a whole) then you will soon find that you don't have any concrete answers.
Yep, I meant quicwg/base-drafts. This document should provide some advice to application mappings other than HTTP on how/whether to use ALPN, but that advice really will depend on the larger discussion of what ALPN means (is is app-only, a stack designator, or something in between). Having that discussion in this draft is probably not the right thing to do, so holding this issue open until it converges in TLS/HTTP/QUIC.
Probably it would be good to have a more general section on service discovery and point to the HTTP/3 doc as one example.
Create a new section in applicability, and reference the -http draft section 3.1 as an example.
Change:
A YANG Data Model for Layer 0 Types - Revision 2 <del> draft-ietf-ccamp-layer0-types-ext-00 </del> <ins> draft-ietf-ccamp-layer0-types-ext-01 </ins> Abstract

Discussion:
draft-ietf-ccamp-layer0-types-URL for IETF 112 submission --> draft-ietf-ccamp-layer0-types-ext-URL This revision of the I-D includes the latest YANG model update - see
Submission checks passed (URL):
Thanks!Minor editorial OLD  NEW file "EMAIL"
Change:
does not cause the endpoint to change its acknowledgement behavior. Endpoints MUST NOT remember the value of the min_ack_delay transport <del> parameter they received.  Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT. </del> <ins> parameter they received for use in a subsequent connection. Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT. </ins> This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.

Discussion:
and provides some further clarification as it was easy to wrongly read to which endpoint the minackdelay applies to. I guess to avoid confusing this could be even called something like capableminack_delay but not sure if that makes a bug difference.
Not remembering it at all would be rather pointless :) I think the authors intended to add, " for use in a subsequent connection."
Yes, this sentence also confused me a lot!
I don't believe the draft says which takes precedence if the Ack-Eliciting Threshold results in the data receiver having to send an ACK sooner than the minackdelay. I believe the draft ought to say that minackdelay takes precedence over Ack-Eliciting Threshold if the two conflict. My reasoning is that a processor needs time before it thinks about a threshold, similar to the reasoning behind §7.3 on Batch Processing of Packets, which says: But I wouldn't fight hard, if someone has better reasoning against this order of precedence.
The minackdelay is an indication from the sender of this information that it practical is not able to send acks faster, e.g. because of the timer granularity. I tried to clarify this in PR NAME does this resolve this issue?
Closing as was merged. Please reopen or open new issue if still not clear!
Looks good, with a few minor textual improvements suggested.
Change:
between paths, the update to the set of available paths can trigger the connection to be migrated. <del> In case of Pooled Connections pooled-connections, the Transport </del> <ins> In the case of a Pooled Connection pooled-connections, the Transport </ins> Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection <del> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application.  The strategy to do so is implementation- specific, but should be consistent with the behavior of multipath transports. </del> <ins> Properties.  In the case that a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application.  The strategy to do so is implementation-specific, but should be consistent with the behavior of multipath transports. </ins> 8.

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload. <del> The client instance presents the signed object in compact form RFC7515 in the Detached-JWS HTTP Header field. </del> <ins> The signer presents the signed object in compact form RFC7515 in the Detached-JWS HTTP Header field. </ins> In this example, the JOSE Header contains the following parameters:

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use
Change:
the remote peer.  This boolean becomes false when "Timeout for aborting Connection" (see conn-timeout) is used. <del> 7.2.4. groupConnLimit Numeric (with special value "Unlimited") Unlimited This property controls the number of Connections that may arrive from a peer as new members of the Connection's group.  Similar to SetNewConnectionLimit(), this limits the number of ConnectionReceived Events that will occur, but constrained to the group of the Connection associated with this property.  In case of a multi- streaming transport, this takes the role of a limit on the number of allowed streams. </del> 7.3. During the lifetime of a connection there are events that can occur

Discussion:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.
Change:
3.1.2. A simplified Background-Check Model may exist in a very specific <del> case. This is where the Relying Party and Verifier functions are co- </del> <ins> case.  This is where the Relying Party and Verifier functions are co- </ins> resident.  This model is appropriate when: Some hardware-based private key is used by an Attester while

Discussion:
Based on request from Yogesh for a new Configuration encoded claim.
Thanks Eric! As you may have guessed, we have an immediate use for this 36 :-)
Change:
IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type <del> 25.  IANA is requested to reserve the content type range 32-63 so </del> <ins> 26.  IANA is requested to reserve the content type range 32-63 so </ins> that content types in this range are not allocated. IANA is requested to allocate two values in the "TLS Handshake Type"

Discussion:
DTLS recommends using 25 as the ACK Content Type. CID is using that number based on an early IANA assignment will change DTLS.
Change:
associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the peer.  The secret key used to sign a credential corresponds to the <del> public key of the peer's X.509 end-entity certificate. </del> <ins> public key of the peer's X.509 end-entity certificate RFC5280. </ins> A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways:

Discussion:
Updating x690 version to match TLS1.2 (2015) Expanding acronyms (avoid genart) removed "!" from some refs (unneded) r/LURK/KEYLESS (completes derference from earlier PR).
Change:
As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to <del> at most 360p.  In this case, the implemention would generate this </del> <ins> at most 360p.  In this case, the implementation would generate this </ins> attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]

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:
"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. <del> The requests are represented as application/dns-udpwirefomat typed bodies. </del> <ins> The requests are represented as message/dns typed bodies. </ins> The first example request uses GET to request www.example.com

Discussion:
The media type has been the subject of some debate. The above might be the best I've seen.
Change:
client instance wants to optimize its calls to the AS before making a request, it MAY send an HTTP OPTIONS request to the grant request endpoint to retrieve the server's discovery information.  The AS MUST <del> respond with a JSON document containing the following information: </del> <ins> respond with a JSON document with Content-Type "application/json" containing a single object with the following information: </ins> The information returned from this method is for optimization purposes only.  The AS MAY deny any request, or any portion of a

Discussion:
The specification can also say a bit stricter A response MUST use the 200 OK (HTTP status code) and return a JSON object using content type.
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 9f7633b4fd5b90bbac20a33ade1e56045a47b3c1 Inspect the deploy log: Browse the preview:
Change:
(ICE), for Network Address Translator (NAT) traversal for UDP-based communication. <del> Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </del> <ins> When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote

Discussion:
Ok.
Looks good.
Where: Introduction What: s/candidate addresses/ICE candidates Why: An address is just one part of a candidate
I tend to think this is implicit, and won't confuse anyone.
We use "candidates" everywhere else, and it is not only the addresses that are exchanged.
8445 also uses 'candidate transport addresses' in Section 2. But open to some other text here, 'ICE candidates' feels like it doesn't explain enough to the reader.
The paragraph says: "Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established. If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed." If people don't understand what an "ICE candidate" is they won't understand the rest of the text either :) My point is that endpoints are exchanging candidates. The candidate transport addresses are then used for sending connectivity checks. So, if you want to include it, perhaps something like: "and then test each candidate pair, by sending connectivity checks using the candidate transport addresses, to see if...."
Implemented in
Reworded, PTAL.
Change:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay (the latter mainly caused by the asymmetric crypto operations associated with the TLS handshake) at both sides. </del> <ins> necessarily includes any transport- and application-layer delay at both endpoints. </ins> 3.8.2.

Discussion:
URL, why are we so specific about TLS crypto operations here, it could be anything like later mentioned (waiting for a response to be send) or simply work load in the endpoints. Overall the inclusion of the transport- and application-layer delay in RTT measurements has been described in different ways without mentioning why one matters more than the others in certain context while pointing to same thing. This need to be fixed.
The section you noted, is about the the handshake. As there is no data during the handshake, the main app-layer delay would be the crypto. Yes, there can always be additional random delays due to processing also on the NIC but these are usually smaller and therefore less relevant. Not sure what kind of change would be needed here.
it would be good to refer to same events that may cause application-layer delay, rather giving two different examples for the same application-layer delay.
Still not sure what you would like to see here. Can you make a proposal?
Alternate proposal: remove the example?
would actually work, but there are examples of application-layer delay in that later section, may be you want to bring that up here and only use one set of potential reasons for application-layer delay for the whole section.
Change:
5.1. DATAGRAM frames belong to a QUIC connection as a whole, and are not <del> strongly associated with any stream ID at the QUIC layer.  However, it is expected that applications will want to differentiate between </del> <ins> associated with any stream ID at the QUIC layer.  However, it is expected that applications will want to differentiate between </ins> specific DATAGRAM frames by using identifiers, such as for logical flows of datagrams or to distinguish between different kinds of datagrams.

Discussion:
From list discussion: What does "strongly associated" mean in this context? We should remove "strongly".
I agree, removing strongly seems best
Thank you!
Change:
The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary <del> data values.  In order to simplify processing of the data values this document proposes to specify a new SenML field for indicating the Content-Format of the data. </del> <ins> data values.  In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. </ins> 1. <del> The Sensor Measurement Lists (SenML) media type RFC8428 can be used </del> <ins> The Sensor Measurement Lists (SenML) media types RFC8428 can be used </ins> to send various kinds of data.  In the example given in ex-1, a temperature value, an indication whether a lock is open, and a data value (with SenML field "vd") read from an NFC reader is sent in a

Discussion:
Alexey notes (Archived-At: ): Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference. (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.) This course of action would probably delay data-ct a bit; we might counteract the damage by early registration. Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.
I didn't do thorough review of the ABNF but otherwise looks good to me Hi all, Sorry for the belated review. I think the document is nearly ready for progression. I have a couple of minor related issues: Terminology Readers should also be familiar with the terms and concepts discussed in [RFC8428]. Awareness of terminology issues discussed in [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it should be revived. (Or see below) helpful. SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document. Best Regards, Alexey
Change:
algorithm to be used for signatures in MLSPlaintext and the tree signatures.  It MUST be the same as the signature algorithm specified in the credential field of the KeyPackage objects in the leaves of <del> the tree (including the InitKeys used to add new members). </del> <ins> the tree (including those used to add new members). </ins> To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below:

Discussion:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Change:
Each endpoint in the system must agree on the configuration for each task, which is defined using the Param structure: <del> "nonce": A unique sequence of bytes used to ensure that two </del> <ins> "uuid": A unique sequence of bytes used to ensure that two </ins> otherwise identical "Param" instances will have distinct "TaskID"s.  It is RECOMMENDED that this be set to a random 16-byte string derived from a cryptographically secure pseudorandom number

Discussion:
Apply to clean up some other whitespace stuff, too.
Because you'll also want a "jitter buffer" on the receiver side and that means something different. Instead of having a random value, why not just have time be to a nanosecond clock and then lexically sort between collisions?
Which will also help one remove duplicates.
Yeah, this is a bad name :)