jiebi/CodeConvo huggingface dataset:
Change:
codepoint for only the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first. <del> Implementations MAY experiment with and use other strategies for use of ECN.  Other methods of probing paths for ECN support are possible, as are different marking strategies.  Implementations can also use the ECT(1) codepoint, as specified in RFC8311. </del> <ins> Other methods of probing paths for ECN support are possible, as are different marking strategies.  Implementations MAY use other methods defined in RFCs; see RFC8311.  Implementations that use the ECT(1) codepoint need to perform ECN validation using ECT(1) counts. </ins> 13.4.2.2.

Discussion:
Taking Gorry's suggestions, which seem quite reasonable.
(1) NiT: /The ECN counter for the ECN codepoint received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram./ mixed singular and plural - is this /counters/? (2) I like this phrase in the security considerations also from the point of view of how to generate transport feedback for ECT(?). Can we call this out here: /QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed/ (3) General experiments are not permitted in RFC8311, only using experimental RFCs. I think therefore, we should be clear in the detail here: /Implementations MAY experiment with and use other strategies for use of ECN. Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations can also use the ECT(1) codepoint, as specified in {{?RFC8311}}./ I’d propose something more like this: /Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations MAY use other methods defined in RFCs, as specified in {{?RFC8311}}. Implementations that use the ECT(1) codepoint, need to perform ECN validation using this code point./
Change:
When the AS issues an access token for use at an RS, the RS needs to have some means of understanding what the access token is for in order to determine how to respond to the request.  The core GNAP <del> protocol makes no assumptions or demands on the format or contents of the access token, and in fact the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </del> <ins> protocol makes neither assumptions nor demands on the format or contents of the access token, and in fact, the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </ins> Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call

Discussion:
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: ee6b3fc9832467191449ff86c6651ebf548d33ea :mag: Inspect the deploy log: :sunglasses: Browse the preview:
A couple of other minor things it sounds to me like an optional step for the RS to validate the signature if the key object is presented in the introspection response. That should be MUST, right? The third step in section "Token Introspection" states that I think that the AS should validate the RS's request and only after that the AT's value.
The RS always has to validate the signature, but sometimes it can't fully validate it until after it looks up the token's data using introspection. We should look at what OAuth MTLS and DPoP say in terms of RS validation steps. The intent of the language for the AS validation was not to imply an order in either direction, so we can look to tweak this to make that more clear.
Change:
9.2. This document registers one new ND option type under the sub-registry <del> "IPv6 Neighbor Discovery Option Formats": </del> <ins> "IPv6 Neighbor Discovery Option Formats" of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry: </ins> Resource Directory Address Option (TBD38)

Discussion:
rather than only referring to the subregistry's name See-Also: URL I concur with my colleagues who commended the authors for making the document very readable. I support Roman's first two DISCUSS points. In Section 9.2, you might want to mention that you're talking about a sub-registry under "Internet Control Message Protocol version 6 (ICMPv6) Parameters". In Section 9.3, you enumerate six fields in each registration, but the initial table of entries has only five columns. It's obvious (I think) that the sixth column would be "this document" for all entries, but I suggest that you should either include the column or some prose making this explicit (since everything else is).
Change:
versions without retaining state.  Though either the Initial packet or the Version Negotiation packet that is sent in response could be lost, the client will send new packets until it successfully receives <del> a response or it abandons the connection attempt.  As a result, the client discards all state for the connection and does not send any more packets on the connection. </del> <ins> a response or it abandons the connection attempt. </ins> A server MAY limit the number of Version Negotiation packets it sends.  For instance, a server that is able to recognize packets as

Discussion:
There was a sentence in this section that seems to be specifying how to handle a version negotiation packet, not how to send one, and as such is out of place.
I can see how this duplicates text from the next section and so is safe to remove. Thanks for separating and providing independent justification. I missed the justification before.
Change:
connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". Reducing the dynamic table capacity can cause entries to be evicted <del> (see eviction).  This MUST NOT cause the eviction of blocking entries (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </del> <ins> (see eviction).  This MUST NOT cause the eviction of entries which are not evictable (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </ins> 4.3.2.

Discussion:
Acting on NAME suggestion.
Thank you, this greatly improves clarity.
Technically, all reviews request rather than require. Those are good suggestions, though.
Incorporated, though the parenthetical reads even more awkwardly now. Suggestions on improving that (or consensus to drop it) are welcome.
This review suggests changes, not "requires" them.
Change:
encrypting other values).  Those usages MUST have their own HKDF labels to avoid reuse. <del> [[OPEN ISSUE: If in future you were to reuse these keys for 0-RTT </del> <ins> [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT </ins> priming, then you would have to worry about potentially expanding twice of Z_extracted.  We should think about how to harmonize these <del> to make sure that we maintain key separation.  Similarly, if the server uses the same key for ESNI as it does in ServerKeyShare, this is going to involve re-use of Z in some hard to analyze ways.  Of course, this would also involve abandoning PFS.]] </del> <ins> to make sure that we maintain key separation.]] </ins> This value is placed in an "encrypted_server_name" extension.

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
CAPPORT Architecture <del> draft-ietf-capport-architecture-01 </del> <ins> draft-ietf-capport-architecture-latest </ins> Abstract

Discussion:
Using these tools should help make things run a little more smoothly. I'll setup a push to gh-pages if you think that this is a good plan.
Hmmm. We should probably deal with this merge conflict. :)
Deconflicted. It was trivial to do on the command line.
Change:
object including data related to the challenge.  The validation object covered by the signature has the following fields: <del> The string "proofOfPossession" </del> <ins> The string "proof-of-possession" </ins> A list of identifiers for which the holder of the prior key authorizes the new key

Discussion:
awesome thanks :+1:
Any reason for the inconsistent naming of the challenge types? Specifically vs Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent. I would personally avoid camelcase in that context since there is already a lot acronyms.
Change:
I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation <del> specifies that attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections. </del> <ins> specifies that attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:

Discussion:
Page 37 contains a statement that "attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections". Two issues: this reads as normative, so consider "SHOULD NOT" rather than "should not." Also, I think this is true of bundle-only sections, not bundled sections in general.
If we are going to use normative language, seems like we should match the language from BUNDLE, which probably says 'MUST NOT'. The statement is correct regarding any actively bundled sections (which includes bundle-only), but this part of the text has caused enough confusion that some extra explanation is probably warranted.
Change:
application protocol and associated service to which processes connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today <del> due to encapsulation, mechanisms for dynamic port assignments, and NATs. </del> <ins> due to encapsulation and mechanisms for dynamic port assignments, as also noted in RFC6335. </ins> As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For

Discussion:
The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
There's an example in that makes this true enough for QUIC that I'd like to say something about it: UDP 443 doesn't mean QUIC, and it doesn't even mean HTTP/3 over QUIC, and HTTP/3 over QUIC doesn't imply UDP 443 because... well, of HTTP semantics (but I do think Paul is right here -- "appearing in a URL" is probably the most widely used form of dynamic port assignment today).
I've sent a reply to Paul by email and waiting for a response now.
For the record this is my mail reply: "[MK] There is actually an example: Microsoft's SMB-over-QUIC uses 443. I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443. However, do you think any changes to the text are needed? If so, can you be more concrete?"
RFC6335 also says this I removed NAT as we only talk about dest port here and added another reference to RFC6335 in PR
Change:
last parameter, "outer_hello", is computed by serializing ClientHelloOuter with the "encrypted_client_hello" extension set to the empty string, i.e., the "extension_data" list has zero length. <del> Note this serialization does not include the four-byte header included in the Handshake structure. </del> <ins> This serialization uses the ClientHello structure from Section 4.1.2 of RFC8446, which does not include the four-byte header included in the Handshake structure. </ins> The decompression process in encoding-inner forbids "encrypted_client_hello" in OuterExtensions.  This ensures the

Discussion:
ClientHello is already a defined structure. No need to wrap it in an opaque byte array. This avoids needing to fill in an extra length prefix in front.
Isn't the length prefix there in order to prevent ossification?
Could you elaborate? I don't see how this relates to ossification. Note AAD values aren't parsed or even sent over the wire. Rather, the requirement on them is injectivity.
If the thinking is one might want to change what goes in the AAD later, the length prefix doesn't do anything. You'd need an actual distinguishing field like a type or version. We get that via labels and such when setting up the ECH context itself. By the time we've settled on speaking a particular ECH-like protocol, the AAD structure is fixed.
Thanks for the clarification. I was confused about the specifics of how this prefix was used.
Can probably just say instead of leading with , which is almost always unnecessary.
Change:
6. <ins> This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints specified to operate over QUICv1 can also operate over this version of QUIC. 7. </ins> QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.

Discussion:
One way to
I have a feeling you'll need to say that this "updates" HTTP/3.
on slack some are saying we should roll a new h3 ALPN for running over quicv2. I cannot quite follow the argument but this is a better venue for the discussion.
You definitely need a new specification, because a different QUIC version might not be suitable. You either say: h3 can be used with QUICv2, or h3q2 (or whatever new string you like) identifies HTTP/3 when running over QUICv2. There are lots of arguments as to why you might choose to do one or the other.
I'm swayed more toward a new ALP.N at the moment
FWIW we painted ourselves into this corner. We punting on the problem and simply tied H3 to v1. Now we are actively trying to solve VN we might be able to pay back the tech debt. For example, a document that updates H3 to say that it can work over versions compatible with v1. Incompatible versions could still need to defined as a new application mapping,
Whatever we do, I think we need to ensure that servers can give sufficient information to clients via Alt-Svc so that the client can pick a compatible version (if any) and avoid VN. This could, then, be solved via Alt-Svc layer or via ALPN, but I think this is any important property.
Well "avoiding VN" is only important to the extent that we can't do compatible VN.
I think we want to allow the existence of a server that only supports v2 and servers that only support v1.... and clients that only support v2 and clients that only support v1. Given this, there will be client : server pairs which do not support any mutually compatible options. It seems like it would be desirable for clients to be able to deduce this from Alt-Svc without needing to see the QUIC connection to the server fail?
Oh, and this text from the HTTP/3 docs is probably relevant:
Change:
where "sk" is the HPKE secret key, "task_id" is "AggregateReq.task_id" and "server_role" is the role of the server <del> ("0x01" for the leader and "0x00" for the helper). "nonce" and "extensions" are obtained from the corresponding fields in "AggregateSubReq".  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.]  Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PPM protocol. </del> <ins> ("0x02" for the leader and "0x03" for the helper; "0x01", the client role, is used as the sender). "nonce" and "extensions" are obtained from the corresponding fields in "AggregateSubReq".  If decryption fails, then the sub-response consists of a "decryption error" alert. [See issue#57.]  Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PPM protocol. </ins> After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request.

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:
For now, infer from other connectivity events and path_challenge/ path_response frames <ins> 3.1.9. Importance: Extra This event indicates that the estimated Path MTU was updated.  This happens as part of the Path MTU discovery process. </ins> 3.2. 3.2.1.

Discussion:
Updates as that had some problems: used instead of for CDDL type in some of the definitions (not in others)... Made a separate category for the event. It's debatable imo whether it belongs in or , but it shouldn't be its own thing. In general, I feel was approved/merged too soon and this type of things should be checked for future PRs of a similar type.
Changes look good to me. First of all, sorry for messing up the type name. I'm not sure I agree that it was merge too soon though, was open for 3 months, and was approved by one of the editors. Sometimes it's better to make progress instead of not moving at all, even if some cleanup is necessary later.
NAME no problem, I mess up way worse than that :) Let me rephrase that to just "approved" too soon then, instead of "merged" too soon (which is again perfectly understandable with Lucas not used to watching for that type of issue, just wanted to indicate future approvals should).
From the discussion in , it seems better to keep this consistent with other events. Also noticed I forgot to prefix the event with Connectivity and add it to the CDDL list on the bottom...
Sorry if that's a stupid question, but why do we have an and a field here? I thought you can only set it once. Originally posted by NAME in URL
This is a fair question. This is most likely a copy-paste from one of the events (can't find evidence that this was once called StreamTypeUpdated though...) For updates this makes sense, but if the StreamType is only ever set once after becoming known, it would be better to change the definition to e.g., (note, is from ) :
Change:
Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is <del> authorized.  Trusted endpoint authorization is described in the (add ref to new signaling draft here). </del> <ins> authorized.  Trusted endpoint authorization is described in WebRTC Signaling for PERC I-D.ietf-roach-perc-webrtc. </ins> A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects

Discussion:
Changed reference to Tunnel and added an (interim) reference to Roach's PERC signaling draft
Added the actual reference to ietf-roach-perc-webrtc in the body.
LGTM
Change:
2. <del> A server that supports this protocol is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </del> <ins> A server that supports this protocol on one or more URIs is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
this is meant as simpler alternative to . Its much less of a rewrite. consolidates caching rules by moving text adds a new section header "HTTP Exchange" for request and response to fall under moves the wireformat definition out of the http sections by moving text.
NAME NAME wdyt?
I'm not terribly happy with pushing the definition of wireformat to so much later because it will cause HTTP people to maybe miss the salient points. This makes the document feel much more like "HTTPS around DNS" instead of "DNS in HTTPS", but I can live with it. Given that there are more knobs and fiddly bits in the HTTP part than in the DNS part, it's reasonable to put those first. NAME if you're OK with it, say so here and I'll accept. I'll then make some very small editorial changes that I am seeing.
I'm OK with it. Would putting the wire format first help? FWIW I don't think HTTP folks are going to miss bits just because of the position in the doc.
Thanks all. I think this is on balance a useful change. I'll fix the bitrot and merge.
Change:
This document recognizes three general categories of Attesters. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor <del> which continually hashes security measurements in a way which prevents an Attester from lying about measurements which have been extended into the Attesting Environment (e.g., TPM2.0.) </del> <ins> which hashes one or more streams of security measurements from an Attester within the Attesting Environment.  Maintenance of this hash enables detection of an Attester which is lying about the set of security measurements taken.  An example of a HSM is a TPM2.0 TPM2.0. </ins> Process-based: An individual process which has its runtime memory encrypted by an Attesting Environment in a way that no other

Discussion:
I want to wait until we have the new definitions being worked in the CCC nailed down. (They look like they are getting close.) Then we can just reference or copy these. Eric
WFM. I have raised to track this.
LGTM, I've left a note unrelated to the change, but close enough to maybe deserve being addressed in the same PR?
Change:
with a value of '*'; see Section 7.1 of SEMANTICS. All HTTP/3 requests MUST include exactly one value for the ":method", <del> ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request; see connect. </del> <ins> ":scheme", and ":path" pseudo-header fields, unless the request is a CONNECT request; see connect. </ins> If the ":scheme" pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the

Discussion:
This PR covers questions asked during Auth48 which aren't pure copyediting, but seem to have a straightforward single-location fix. Individual commits, so it's easy to pull one out if someone disagrees.
In , the RFC Editor asks:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .