jiebi/CodeConvo huggingface dataset:
Change:
length, or three octets in length.  The length of the OHB indicates what data is contained in the extension. <del> If the OHB is one octet in length, it contains both the original X bit and PT field value.  In this case, the OHB has this form: </del> <ins> If the OHB is one octet in length, it contains the original PT field value.  In this case, the OHB has this form: Note that "R" indicates a reserved bit that MUST be set to zero when sending a packet and ignored upon receipt. </ins> If the OHB is two octets in length, it contains the original RTP packet sequence number.  In this case, the OHB has this form: <del> If the OHB is three octets in length, it contains the original X bit, PT field value, and RTP packet sequence number.  In this case, the OHB has this form: </del> <ins> If the OHB is three octets in length, it contains the original PT field value and RTP packet sequence number.  In this case, the OHB has this form: </ins> If an MDD modifies an original RTP header value, the MDD MUST include <del> the OHB extension to reflect the changed value.  If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB.  To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </del> <ins> the OHB extension to reflect the changed value, setting the X bit in the RTP header to 1 if no header extensions were originally present. If another MDD along the media path makes additional changes to the RTP header and any original value is not already present in the OHB, the MDD must extend the OHB by adding the changed value to the OHB. To properly preserve original RTP header values, an MDD MUST NOT change a value already present in the OHB extension. </ins> 5.

Discussion:
2) s2.2.2, : I gotta ask why the MessageType byte isn’t first? Wouldn’t putting the MessageType first allow you avoid buffering everything before proceeding? It seems like you’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations.
Change:
Eventually, if the nominations succeed, both the controlling and controlled agents will have a single nominated pair in the valid list for each component of the data stream.  Once an ICE agent sets the <del> state of the check list is set to Completed (when there is a nominated pair for each component of the data stream), that pair becomes the selected pair for that agent, and is used for sending and receiving data for that component of the data stream. </del> <ins> state of the check list to Completed (when there is a nominated pair for each component of the data stream), that pair becomes the selected pair for that agent, and is used for sending and receiving data for that component of the data stream. </ins> If an agent is not able to produce selected pairs for a data stream, the agent MUST take proper actions for informing the other agent, and

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <ins> Note: a Singular Query may be used anywhere where a ValueType is expected, so there is no need to use the "value" function extension with a Singular Query. </ins> 2.6.9. 2.7.

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
flight.  A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a <del> congestion window and an estimated RTT, respectively. </del> <ins> congestion window and an estimated RTT, respectively.  If the sender is application-limited, a large ack delay can delay acknowledgement information unnecessarily when entering idle periods.  Therefore, if no further data is buffered to be sent, a sender can send an IMMEDIATE_ACK frame with the last data packet before an idle period to avoid waiting for the ack delay. </ins> 9.2.

Discussion:
Thank you for adding the guidance on a sender's choice of acknowledgment frequency. In the below text, I think we need to be careful about one more scenario - app limited sending behavior. If the sender is sending in a stop and go manner, and it creates ACKFREQUENCY such that it receives one ACK per cwnd (ack-eliciting threshold) or an estimated RTT (Request Max Ack Delay), then it could take a total of 2 RTT for the ACK to come back. A sender can accomplish this by sending an IMMEDIATEACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. For example, if RTT = R sender sends after long idle period at time t (there are no outstanding bytes in flight) receiver receive packet at t + R/2 (one way propagation time) receiver waits for 1R and then sends ACK sender will receive ACK at (t+R/2) + 1R ( Max ack delay) + R/2 Perhaps, we could handle the app-limited scenario in guidance by saying, An app-limited sender SHOULD send an IMMEDIATE_ACK frame at the start of a new send cycle OR (More generic solution) The receiver SHOULD send an ACK after, MIN( time equivalent to Request Max Ack Delay has elapsed from the last ACK, Request Max Ack Delay from when it received data) I like option 2 as this covers the different sending behaviors.
Yes, in the case you describe, it could take 2 RTTs to get feedback for sending a single packet. Are there problems you expect this to cause? The same is true of RFC9000 if peer's maxackdelay is >= RTT. I can imagine recommending sending an IMMEDIATE_ACK at the end of a send cycle to mitigate this, but I'm not sure what the goal of sending one at the beginning is?
I created PR Does this guidance make sense?
Change:
8.1.  URIs [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del>

Discussion:
Expands discussion of RS authentication, with examples. Re-uses structures from client instance auth used in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 71b0e6f2bdaa5a34903865e3130160be29eefc4b :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Change:
that a device is running a weak version of firmware provides a way to aim attacks better. <del> Many Claims in Evidence and Attestation Results are potentially Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that goes up to include containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </del> <ins> Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </ins> In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the

Discussion:
Fixes issue
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
`
Yes. However, without a suitable privacy tracking identifier, it might not be possible to correlate privacy sensitive information in the policy with the actions of the Attester.
We should add privacy applies to appraisal policy to Privacy section.
Change:
analysis and padding, or migration might be relevant for other applications using QUIC as well. <del> 15. </del> <ins> 16. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Discussion:
I updated the text of the second paragraph. If people could have another look that would be welcome. But I believe we are ready to merge (after the meeting).
So far we don't mention any extension in the ops drafts, however, datagrams actually require a different interface and as such are important for an application to know about, therefore, I think it would be good to add a separate section in the applicability statement and mention it as a separate service over QUIC.
Agreed, mentioning datagram seems very useful.
Change:
When the decoder encounters an invalid static table index in a header block representation it MUST treat this as a connection error of type <del> "HTTP_QPACK_DECOMPRESSION_FAILED".  If this index is received on the encoder stream, this MUST be treated as a connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". </del> <ins> QPACK_DECOMPRESSION_FAILED.  If this index is received on the encoder stream, this MUST be treated as a connection error of type QPACK_ENCODER_STREAM_ERROR. </ins> 3.2.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
4.2.1. <del> Immediate racing is when multiple alternate branches are started </del> <ins> Simultaneous racing is when multiple alternate branches are started </ins> without waiting for any one branch to make progress before starting the next alternative.  This means the attempts are effectively <del> simultaneous.  Immediate racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </del> <ins> simultaneous.  Simultaneous racing should be avoided by implementations, since it consumes extra network resources and establishes state that might not be used. </ins> 4.2.2. <del> Delayed racing can be used whenever a single node of the tree has </del> <ins> Staggered racing can be used whenever a single node of the tree has </ins> multiple child nodes.  Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay.  Once that second

Discussion:
Opening this to follow up on a comment by NAME on that is now closed. "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)
I agree this would be an improvement.
LGTM (of course :-) )Thanks, looks good!
Change:
Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others <del> are marked "No".  This new column is intened to alter the </del> <ins> are marked "No".  This new column is intended to alter the </ins> incorrect perception that getting a code point somehow legitimizes <del> the extesion, cipher suite/algorithm, or exporter. </del> <ins> the extension, cipher suite/algorithm, or exporter. </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS

Discussion:
Added the guidelines from RFC 5705
Need to add designated expert instructions for exporters like we did for ExtensionType, Cipher Suite, and ClientCertificateType Identifiers registries.
Also addressed by .
Change:
8. <ins> Security considerations are provided throughout this document.  It bears repeating that there are concerns related to the use of external PSKs regarding proper identification of TLS 1.3 endpoints and additional risks when external PSKs are known to a group. </ins> It is NOT RECOMMENDED to share the same PSK between more than one client and server.  However, as discussed in use-cases, there are application scenarios that may rely on sharing the same PSK among

Discussion:
This deals with many comments from the AD Evaluation. The comment on section 6.1 still needs to be resolved, and the NITS need to be addressed.
Chris's suggestions generally seem reasonable
Change:
1-RTT (short-header) <del> A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial or Handshake packets. </del> <ins> Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake packets. </ins> Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets.

Discussion:
The first inverts the description of "ih" to be clearer. The second makes it clearer for IANA that the "packets" column can be ignored.
Change:
that all intermediaries are fully trusted and have not been compromised. <ins> Counting Echo values can only be used to show freshness relative to numbered events, and are the legitimate case for Echo values shorter than four bytes, which are not necessarily secret.  They MUST only be used when the request Echo values are integrity protected. </ins> Servers SHOULD use a monotonic clock to generate timestamps and compute round-trip times.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is

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:
echo-state to minimize the memory impact of having many unanswered Echo responses. <ins> CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD NOT cache responses when a Echo option is present in request or response for more than the exchange.  CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (eg. because it is a PUT or POST); how this is determined is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond to Echo challenges themselves, as they know that the HTTP request is fresh, and can not forward the option anyway. </ins> 2.3. Actuation requests often require freshness guarantees to avoid

Discussion:
This opens up questions in URL Closes: URL
Like OSCOAP asked that new options declare themselves E or U, the HTTP mapping document asked for clarification what a cross proxy should do. Looks like both Repeat and Request-Tag are never expressed in HTTP, and that a cross proxy needs to repeat the request or run an operation with a Request-Tag just as a CoAP client; a CH proxy (CoAP server) needs to use its own discretion on when to ask for a Repeat.
Change:
Initial contents: The fields and descriptions defined in account- objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.2. This registry lists field names that are defined for use in ACME

Discussion:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:
Change:
a later date, but should not provide a security service based on guesses of what is there. <del> NOTE: Alternative syntax with tags would be Where we would need to define the latter two as tagged arrays like is currently done for COSE_SignedMessage. There is no space savings in CBOR, this is strictly about using CBOR paradymes.  It is not clear what would happen if a JOSE serialization appeared, but that is probably not interesting.  If this path is used, then there is no extensibility for new messages types.  They would need to be defined on their own. </del> 3. The signature structure allows for one or more signatures to be

Discussion:
Fix install instructions in the README for kramdown-xml2rfc Update COSE spec for tagging discussion Update Issues document for closed and newly opened discussion issues.
Carsten has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures. Should this be done?
a) CBOR Tag - either general or specific to each type b) Required Identifier c) Use the same techniques as JOSE There was no support for option C. There was support for Option B There was some support for Option A, but only if it was optional. Mike Jones suggested that we should use the header parameter 'typ', I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the JWS document. At this point I will keep the field as mandatory and outside of the headers field. I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text.
Closed in Pull request
Change:
Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism. <del> The Relying Party role is assigned to entities that uses Attestation </del> <ins> The Relying Party role is assigned to an entity that uses Attestation </ins> Results by applying its own appraisal policy to make application- specific decisions, such as authorization decisions.  This procedure is called the appraisal of Attestation Results.

Discussion:
The Relying Party role is assigned to entities that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions. should be >The Relying Party role is assigned to entities that use Attestation Results by applying their own appraisal policies to make application-specific decisions, such as authorization decisions. or >The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.
I'm in favor of the second option: The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.
I am okay with second option.
Change:
The JWK representation of the old key. <del> The client then encapsulates the key-change object in an "inner" JWS, </del> <ins> The client then encapsulates the keyChange object in an "inner" JWS, </ins> signed with the requested new account key.  This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request.

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
Expert, that Expert SHOULD defer to the judgment of the other Experts. <del> 15. </del> <ins> 16. </ins> The authors are fairly certain that there are no security considerations for this document. <del> 16. </del> <ins> 17. </ins> This document is entirely about changes to TLS-related IANA registries.

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a <del> type advertised by the client in the "signature_algorithms" extension and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </del> <ins> type advertised by the client in the SignatureSchemeList and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </ins> 3.1.2.

Discussion:
Hearing no objections on the list, merging this in. NAME can you please spin a new version for WGLC?
Allow the client to send a list of signature schemes that are supported in a delegated credential handshake.
Fixed by .
Change:
When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute <del> information to contact the IdP, and verify the identity of the peer. If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </del> <ins> information to contact the IdP and verify the identity of the peer. If the identity requires a third-party IdP as described in sec.trust- relationships then that IdP will need to have been specifically configured.  If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </ins> 5.1.4.

Discussion:
We'll leave this for later.
What's generic is the protocol, but if you have a third party IdP, trust has to be configured. Say that and point to 7.1
See also 5.1.3. Forward reference to 7.1