jiebi/CodeConvo huggingface dataset:
Change:
or the rate at which validation can be requested within a given subtree of the DNS. <del> 10.5. </del> <ins> 10.4. </ins> The controls on issuance enabled by ACME are focused on validating that a certificate applicant controls the identifier he claims.

Discussion:
This PR is a re-do of . It only removes recovery; it does not add the "account-mgmt" metadata item.
LGTM
We removed recovery in . If we refactor roll-over as proposed in , however, recovery can be done much more simply, at least if you assume the client is provisioned with a MAC key (possibly out of band).
Agreed at IETF 96 that we will not specify recovery. Instead, we will add some guidance for CAs as to how to handle loss of account keys.
Change:
boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained <del> securely.  If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. </del> <ins> securely.  If an attacker can configure or modify appraisal policies, Endorsements or Reference Values for a Relying Party or for a Verifier, then integrity of the process is compromised. </ins> Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format.

Discussion:
May be duplicated by dthaler pull request , second part might belong in privacy considerations instead of here. NAME to redraft.
** Section 12.2 It is also important that the appraisal policy was itself obtained securely. If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. In addition to reconfiguration, wouldn't the ability to intercept either the appraisal policy for evidence or attestation results potentially provide the attacker insight into defensive mitigations? This suggests that this policy might need confidentiality protection.
see .
Maybe fixed this one along with
-- The overall Section 12 seems silent on: o Endorsers and endorsements? o Reference values? o What is the implication of combining roles into a single entity as described in Section 3.4 and 6. Does this lack of separation present any additional issues? o Compositional devices per Section 3.3?
"If an attacker can modify appraisal policies, Endorsements, or Reference Values, then integrity of the process is compromised."
`
maybe already fixed with recent changes
maybe helps?
Change:
initial registration, a default value of 86400 (24 hours) SHOULD be assumed. <del> Context (optional).  This parameter sets the scheme, address, port and path at which this server is available in the form scheme://host:port/path.  In the absence of this parameter the </del> <ins> Context (optional).  This parameter sets the Default Base URI under which the request's body are be interpreted.  The URI scheme provided MUST allow a path component, but the path component of the Context parameter MUST be empty.  The parameter is therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the </ins> scheme of the protocol, source address and source port of the register request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an <del> commissioning tool.  When con is used, scheme and host are mandatory and port and path parameters are optional.  If the endpoint uses an ephemeral port to register with, it MUST include the con: parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </ins> application/link-format

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
Connection.  These connections are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these two Connections adds a third Connection to the Connection Group, and so <del> on.  Connections in a Connection Group share all Protocol Properties that are not applicable to a Message. </del> <ins> on.  Connections in a Connection Group generally share Connection Properties.  However, there may be exceptions, such as "Priority (Connection)", see conn-priority. </ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection: <del> Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del> <ins> Changing one of the Connection Properties on one Connection in the group changes it for all others.  Message Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Connection Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.

Discussion:
When reading the API draft, I noticed that in some places it was still using the outdated term "Protocol Properties" where it actually means Connection Properties or Message Properties. I replaced the terms in this PR. We do still define "Specific Protocol Properties", so I kept these.
Change:
5. <del> An WebTransport session over HTTP/3 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. </del> <ins> A WebTransport session over HTTP/3 is considered terminated when either of the following conditions is met: the CONNECT stream is closed, either cleanly or abruptly, on either side; or a CLOSE_WEBTRANSPORT_SESSION capsule is either sent or received. Upon learning that the session has been terminated, the endpoint MUST reset all of the streams associated with the session; it MUST NOT send any new datagrams or open any new streams. To terminate a session with a detailed error message, an application MAY send an HTTP capsule HTTP-DATAGRAM of type CLOSE_WEBTRANSPORT_SESSION (0x2843).  The format of the capsule SHALL be as follows: CLOSE_WEBTRANSPORT_SESSION has the following fields: A 32-bit error code provided by the application closing the connection. A UTF-8 encoded error message string provided by the application closing the connection.  The message takes up the remainer of the capsule, and its length MUST NOT exceed 1024 bytes. A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the sender side.  If any additional stream data is received on the CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code H3_MESSAGE_ERROR.  The recipient MUST close the stream upon receiving a FIN.  If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it SHOULD send STOP_SENDING on the CONNECT stream. Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string. </ins> 6.

Discussion:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!
Change:
discard packets that are received on a different network path. The Source and Destination Connection ID fields are the primary means <del> of protection against off-path attack during the handshake.  These are required to match those set by a peer.  Except for an Initial and stateless reset packets, an endpoint only accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose.  This is the only protection offered for Version Negotiation packets. </del> <ins> of protection against off-path attack during the handshake; see validate-handshake.  These are required to match those set by a peer. Except for an Initial and stateless reset packets, an endpoint only accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose.  This is the only protection offered for Version Negotiation packets. </ins> The Destination Connection ID field in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose.

Discussion:
NAME said:
I believe that we are perfectly OK for the handshake. We can cite Section 8.1 (again) for this (it's the third paragraph primarily). This is deliberately not specified other places. Mostly because it is hard, but also because any definition would be unnecessarily constraining. I don't agree with Fernando that this absolutely needs specification.
Change:
4. <del> This document requests two new IETF URN protocol parameter (RFC3553) entries.  This document also requests a reallocation of DHCPv4 option </del> <ins> This document requests one new IETF URN protocol parameter (RFC3553) entry.  This document also requests a reallocation of DHCPv4 option </ins> codes (see exp106 for background). Thanks IANA!

Discussion:
Earlier version of this document requested a parameter to be used for Link Relation purposes. This LinkRel use was removed as was the explicit parameter request, but the surround grammar was overlooked. Also: rev draft version to -02 and document month to February in anticipation of post a new version.
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 at </del> <ins> necessarily includes all transport- and application-layer delay at </ins> both endpoints. 3.8.2.

Discussion:
Using the Spin Bit for Passive RTT Measurement ... Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of [acm] suggest s/any/all/ ... Since the spin bit logic at each endpoint considers only samples from packets that advance the largest packet number, signal generation itself is resistant to reordering. However, reordering can cause problems at an observer by causing spurious edge detection and therefore inaccurate (i.e., lower) RTT estimates, if reordering occurs across a spin-bit flip in the stream. [acm] thanks for mentioning this! ... Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT. RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). [acm] (let's avoid the clocky term "jitter", and clarify) Suggest: (which over-estimates one-way packet delay variance as seen by an application end-point).
Change:
The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should be minimized at the expense of efficient use of the available <del> capacity.  This implies that the Connection might fail if the desired rate cannot be maintained across the Path.  A transport can interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate-adaptive congestion controller. Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB. </del> <ins> capacity.  This implies that the Connection might fail if the Path is unable to maintain the desired rate.  A transport can interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate-adaptive congestion controller.  Transport system implementations that map the requested capacity profile onto per- connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB. </ins> The application expects to send/receive data at the maximum rate allowed by its congestion controller over a relatively long period

Discussion:
To address NiTs
I-D.ietf-tsvwg-datagram-plpmtud is now a RFC.
See PR
Resolved in PR
The current text says: Constant-Rate Streaming: The application expects to send/receive data at a constant rate after Connection establishment. Delay and delay variation should be minimized at the expense of efficient use of the available capacity. This implies that the Connection might fail if the desired rate cannot be maintained across the Path. this last sentence sounds a little like the app needs to maintain the rate, rather than the path is expected to offer the rate. Could we change the last sentence to: /This implies that the Connection might fail if the Path is unable to maintain the desired rate. /
See PR
This was fixed in PR
Editorial: This text at the end of the intro reads odd to me: ‘This specific transport stack choice is discouraged for general use, because it can reduce the portability.’ I think it should read more like: ‘This choice, which only permits using a specific transport stack is discouraged for general use, because it can reduce the portability.’ —— Editorial; Is a Connection an instance of the stack? The current text says: ‘A Connection represents a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint’ This may be better as?: ‘A Connection represents an instance if a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint’ —— ‘Editorial ‘through a Message Framer which finds message’ Should this be: ‘through a Message Framer that finds message’
See PR
Resolved in PR
This LGTM, thanks!
Change:
16.2. <del> During each epoch senders MUST NOT encrypt more data than permitted </del> <ins> During each epoch, senders MUST NOT encrypt more data than permitted </ins> by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead- limits. <del> Note that each change to the Group through a Handshake message will </del> <ins> Note that each change to the group through a handshake message will </ins> also set a new "encryption_secret".  Hence this change MUST be applied before encrypting any new application message.  This is required both to ensure that any users removed from the group can no

Discussion:
Interim 2022-05-26: Intended to be mostly editorial Leaving open for now Clear to merge in between meetings if folks are comfortable
Interim 2022-06-02: Still clear from last week
The generation numbers should be increased sequentially, gaps should be avoided to avoid unnecessary expensive operations on clients. Clients might also abort if the gap is too large to prevent attacks from malicious insiders.
This is stated in 10.1:
I suspect that what Raphael is worried about is that a malicious insider (someone in possession of the ) could make an MLSCiphertext with set to that would cause the receiver to do HKDF invocations. The attacker doesn't have to incur this cost because they don't need to generate the required key -- the ciphertext can be garbage because the key generation happens before the decryption does. It seems like we could use a paragraph at the end of covering this and the fact that if you want to allow for out-of-order messages, you need to keep the intermediate keys. Since big gaps would force you to store the keys as well as doing the hashing. A figure here might also be helpful.
Couple of friendly amendments, otherwise lgtm. I am going to hold this as slightly more than editorial, given the number of MUSTs that are affected. But I would note for others that the MUSTs that are removed here are all redundant with requirements above.Thanks for picking this up! Just one nit, but looks good otherwise.
Change:
registrations in this registry are assigned using the Specification Required policy (RFC8126), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards <del> Action or IESG Approval as defined in Section 4.9 and 4.10 of </del> <ins> Action or IESG Approval as defined in Sections 4.9 and 4.10 of </ins> RFC8126. In addition to the fields in iana-provisional, permanent

Discussion:
to make RFC Editor diffs smaller
These are manual; if only there were a tool... Diffs in the are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of URL).
I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick). The changes should be visible at URL if CI ever passes. Which of course it has not at this point...
Seems to be working occasionally; I fixed a lint problem, and diffs are now at URL
NAME I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for and it should consistently show all instances, whether or not there's a section being referenced). If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.
NAME Fair enough. This LGTM.
Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time). URL I've spotted one problem there already, but it does look good so far.
NAME and NAME I have learned something new about kramdown-rfc2629. Cheers.
NAME
NAME and NAME should approveThanks for doing this, recovery LGTM
Change:
QUIC-TRANSPORT): A variable-length integer representing the minimum amount of time <del> in microseconds by which the endpoint can delay an acknowledgement.  This limit could be based on the receiver's clock or timer granularity. </del> <ins> in microseconds by which the endpoint that is sending this value is able to delay an acknowledgement.  This limit could be based on the receiver's clock or timer granularity. 'min_ack_delay' is used by the peer to avoid requesting too small a value in the Request Max Ack Delay field of the ACK_FREQUENCY frame. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat

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:
If, on the other hand, V is the leaf U and its LeafNode has "leaf_node_source" set to "commit", then the Parent Hash of P (with <del> V's sibling as co-path child) is stored in the "parent_hash" field. </del> <ins> V's sibling as copath child) is stored in the "parent_hash" field. </ins> This is true in particular of the LeafNode object sent in the "leaf_node" field of an UpdatePath.  The signature of such a LeafNode thus also attests to which keys the group member introduced into the

Discussion:
The co-path is written both as 'co-path' and 'copath'. As a formality check, this should be unified.