jiebi/CodeConvo huggingface dataset:
Change:
consumer, a buffer, and a transport mechanism that fills the buffer. The consumption rate is fairly static and is represented by the content bitrate.  The size of the buffer is also commonly a fixed <del> size.  The fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced. </del> <ins> size.  The buffer fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced. </ins> The challenges in filling the buffer in a timely way fall into two broad categories:

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
support for one of these versions and can expect that clients ignore the value. <del> [[RFC editor: please remove the remainder of this section before publication.]] The version number for the final version of this specification (0x00000001), is reserved for the version of the protocol that is published as an RFC. Version numbers used to identify IETF drafts are created by adding the draft number to 0xff000000.  For example, draft-ietf-quic- transport-13 would be identified as 0xff00000d. Implementors are encouraged to register version numbers of QUIC that they are using for private experimentation on the GitHub wiki at <https://github.com/quicwg/base-drafts/wiki/QUIC-Versions>. </del> 16. QUIC packets and frames commonly use a variable-length encoding for

Discussion:
Note: Don't merge until the last minute.
I want to do more than just approve this, but this'll have to do
Change:
be the given resource-target, its parent path or the whole Origin (see Section 7 of RFC6454). <del> The rate-limit fields may be returned in both Successful and non Successful responses.  This specification does not cover whether non Successful responses count on quota usage. </del> <ins> The rate-limit fields may be returned in both successful (see Section 15.3 of SEMANTICS) and non-successful responses.  This specification does not cover whether non Successful responses count on quota usage, nor it mandates any correlation between the RateLimit values and the returned status code. </ins> This specification does not mandate a specific throttling policy. The values published in the fields, including the window size, can

Discussion:
clarifies that status code is independent from the values of RL fields the example reflects the above statement.
Would there be scope to define standards for the 429 response or would that be more relevant to RFC6585. Should RFC6585 be extended to mention this RFC ?
This I-D is independent from the status code of the response, so I'd say there are no normative relations between this doc and RFC6585. This is by design: we just want to standardize response fields without explicitly define a "ratelimit protocol". Instead, we want implementers to be free to implement their throttling strategies.
See. URL
I noticed in the example in You return a 200 response with RateLimit-Remaining: 0 . It is not completely clear in the document that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly. In you present a case where the cost of a more expensive call deducts two from the remaining pool and results in a 429. I am conflicted as to whether it should be a server decision whether the call is respected or whether the spec should strictly define this behaviour. I lean toward the former but some feel guidance is needed.
we should clarify that this is a server choice. The spec does not mandate any correlation between the RL values and the returned status code . The server can always decide to serve requests even when quota is over. We need to clarify this both in the text and in the example.
That is something that was not clear to me when reading the spec. The assumption being that when is exhausted, a user will be rate limited and an error response (429) will be issued. It would seem as per and that there is no specific intention to require a server implementation to deny further responses, but rather in some cases the expectation would be for the client to gracefully comply and back off. My feeling is though that this use case would be the exception rather than the rule, with most implementations opting to deny further requests. Should we not at least provide guidance that a 429 response should be issued in this scenario ?
Change:
single octet indicating the length.  Challenges with redemption_context values of invalid lengths MUST be ignored. <del> "origin_name" is an optional string containing the name of the origin, which allows a token to be scoped to a specific origin. The string is prefixed with a 2-octet integer indicating the length, in network byte order.  If empty, any non-origin-specific token can be redeemed. </del> <ins> "origin_info" is an optional string containing one or more origin names, which allows a token to be scoped to a specific set of origins.  The string is prefixed with a 2-octet integer indicating the length, in network byte order.  If empty, any non-origin- specific token can be redeemed.  If the string contains multiple origin names, they are delimited with commas "," without any whitespace. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:

Discussion:
NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!
Change:
3.2. <del> The cloud registrar must determine pledge ownership.  Once ownership is determined, or if no owner can be determined, then the registrar may: </del> <ins> The cloud registrar must determine pledge ownership.  if the registrar is unwilling or unable to handle the voucher request, for example it is unable to determine ownership, then the cloud registrar MUST return a suitable 4xx or 5xx error response to the pledge. If the cloud registrar successfully determines ownership, then the registrar MUST take one of the following actions: </ins> return a suitable 4xx or 5xx error response to the pledge if the <del> registrar is unwilling or unable to handle the voucher request </del> <ins> registrar is unwilling or unable to handle the voucher request for any reason </ins> redirect the pledge to an owner register via 307 response code

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:
offerer to be maintained, and so the subsequent answer will contain an identical "LS" group. <del> The sec.normal-example example later in this document shows a more </del> <ins> The sec.detailed-example example later in this document shows a more </ins> involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is

Discussion:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward
Change:
The digest used in the mask generation function MUST be the same as the digest which is being signed (i.e., what appears in algorithm.signature).  The length of the salt MUST be equal to the <del> octet length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </del> <ins> length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the

Discussion:
This addresses Brian's comment from . We don't use "octet length" anywhere else in the document.
Change:
3. After completing the handshake, endpoints have agreed to enable <del> multipath feature and can start using multiple paths. </del> <ins> multipath feature and can start using multiple paths.  This document does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </ins> This proposal adds one multi-path control frame for path management:

Discussion:
Some more text for the scheduling section to clarify it.
A suggestion to resolve Mirja's point, also agree on the proposed change in line 248.
Change:
receiver.  Prioritization can be realized by the sender and the QUIC transport should provide an interface for applications to prioritize streams QUIC.  Further applications can implement their own <del> prioritization scheme on top of QUIC: an an (application) protocol that run on top of QUIC can define explict messages for signaling </del> <ins> prioritization scheme on top of QUIC: (an application) protocol that run on top of QUIC can define explicit messages for signaling </ins> priority, such as those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
This field is 1 to 4 bytes long.  The packet number is protected using header protection; see Section 5.4 of QUIC-TLS.  The length <del> of the packet number field is encoded in the Packet Number Length </del> <ins> of the Packet Number field is encoded in the Packet Number Length </ins> bits of byte 0; see above. This is the payload of the packet - containing a sequence of

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
rfc8152bis-algs this can be addressed by combining randomness and determinism. <del> The referenced processing instructions in SP-800-56A must be complied with, including deleting the intermediate computed values along with any ephemeral ECDH secrets after the key derivation is completed. The ECDH shared secrets, keys, and IVs MUST be secret. </del> <ins> All private keys, symmetric keys, and IVs MUST be secret. </ins> Implementations should provide countermeasures to side-channel <del> attacks such as timing attacks.  Depending on the selected curve, the parties should perform various validations of each other's public keys, see e.g.  Section 5 of SP-800-56A. </del> <ins> attacks such as timing attacks.  Intermediate computed values such as ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key derivation is completed. </ins> The Initiator and the Responder are responsible for verifying the integrity of certificates.  The selection of trusted CAs should be

Discussion:
This was suggested in CFRG during the discussion on HPKE Elliptic-Curve-Point-to-Octet-String Conversion. The compact representation used in EDHOC can be used whenever compact output is used in ECDH (which it almost always is). Important to differenctiate between the wire format, the validation done, and the algorithm for multiplication. EDHOC only touch the wire format, and do not loosen any validation requirements or recommend any particular algorithms form multiplication. Suggestion oflline that it might be better to specify that the "y-bit" is set to 0 instead of giving the implementor an option. Suggestion offline that the draft should refer to SECG in addition or instead of NIST.
I made a PR trying to capture the suggestion from CFRG. I think the PR is ready to merge.
on page 14 would it not be suitable to add that IDCREDx = { x5chain : certificate in DER }, for x = I or R,
Very timely comment. I just made an update to this effect, see b5346fb. I didn't want to include this kind of notation as it requires explanation. Is it good enough?
Suggest to give it a bullet as well. Göran Selander schreef op 2021-02-22 11:26: Links: [1] URL [2] URL [3] URL
Change:
Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing <del> the packet.  The length of this field is 16 bits. </del> <ins> the packet, within a given conference.  The length of this field is 16 bits, representing a two-byte integer in network byte order.  The parameters identified by this field are: Epoch: This field indicates how many SRTP keys have been sent for this SSRC under the current EKTKey, prior to the current key, as a two-byte integer in network byte order.  It starts at zero at the beginning of a session and resets to zero whenever the EKTKey is changed (i.e., when a new SPI appears).  The epoch for an SSRC increments by one every time the sender transmits a new key.  The recipient of a FullEKTField MUST reject any future FullEKTField for this SPI and SSRC that has an equal or lower epoch value to an epoch already seen. Together, these data elements are called an EKT parameter set.  Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. </ins> EKTMsgLength: All EKT messages types other than the ShortEKTField have a length as second from the last element.  This is the length in

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
5. The availability of a secure pseudorandom number generator and truly <del> random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </del> <ins> random seeds are essential for the security of the Echo option (except when using counting Echo values).  If no true random number generator is available, a truly random seed must be provided from an external source.  As each pseudoranom number must only be used once, an implementation need to get a new truly random seed after reboot, or continously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. </ins> A single active Echo value with 64 (pseudo-)random bits gives the same theoretical security level as a 64-bit MAC (as used in e.g. <del> AES_128_CCM_8).  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </del> <ins> AES_128_CCM_8).  Unless a counting Echo value is used, the Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). </ins> The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to

Discussion:
Closes: URL The numeric part is trivial, the security implications (the use case for short Echo values has a different threat model than what's previously in seccons) is not.
As previously discussed in private mail: For the OSCORE state recovery use case, putting a new sequence number in the Echo option is good enough, and that can be short.
Change:
this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del> <ins> server when using the Web Push protocol RFC8030, but it could be used in other contexts if applicable. </ins> 3.1.

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
supported encoding is necessary only when the "/subscriptions/subscription/encoding" leaf is not configured, per the "encoding" leaf's description statement in the "ietf-subscribed- <del> notification" module.  FIXME: do they need to discover *any* capabilities? </del> <ins> notification" module. </ins> 3.2. To learn the capabilities of a receiver, a publisher can issue an <del> HTTPS GET request to the "capabilities" resource under a known path on the receiver with "Accept" header set using the "application/xml" and/or "application/json" media-types, with latter as the mandatory </del> <ins> HTTPS GET request to the "capabilities" resource (see overview) on the receiver with "Accept" header set using the "application/xml" and/or "application/json" media-types, with the latter as mandatory </ins> to implement, and the default in case the type is not specified. 3.3.

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
above to refer to error types, rather than the full URNs.  For example, an "error of type 'unrecognizedMessage'" refers to an error document with "type" value <del> "urn:ietf:params:ppm:error:unrecognizedMessage". </del> <ins> "urn:ietf:params:ppm:dap:error:unrecognizedMessage". </ins> This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of DPLPMTUD). ICMP message validation MUST include matching IP addresses and UDP <del> ports RFC8085 and, when possible, connection IDs to an active QUIC </del> <ins> ports BCP145 and, when possible, connection IDs to an active QUIC </ins> session.  The endpoint SHOULD ignore all ICMP messages that fail validation.

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
When the server cannot decrypt or does not process the "encrypted_client_hello" extension, it continues with the handshake <del> using the cleartext "server_name" extension instead (see server- </del> <ins> using the plaintext "server_name" extension instead (see server- </ins> behavior).  Clients that offer ECH then authenticate the connection with the public name, as follows:

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
The model shown in fig-ER-RD models the contents of the resource directory which contains in addition to /.well-known/core: <del> 0 to n Registration (entries) of endpoints, </del> <ins> 0 to n Registrations of endpoints, </ins> A registration is associated with one endpoint.  A registration defines a set of links as defined for /.well-known/core.  A

Discussion:
I remember keeping web-links where it was beneficial to the text IMO OK with suggested change Peter chrysn schreef op 2018-11-09 16:43: Links: [1] URL [2] URL [3] URL
I'm fine with "Web Links" not being that prominent in the architecture any more; however, two mentions have survived in the three paragraphs above fig-arch, was that intentional?