jiebi/CodeConvo huggingface dataset:
Change:
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <ins> Additionally, Application-Layer Version Negotiation RFC7301 permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered. Applications using QUIC should register an ALPN token for use in the TLS handshake. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the <del> "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del> <ins> "h3" ALPN token.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of

Discussion:
First stab;
Sorry I missed this during the WGLC. URL contains a lot of good stuff but it seems like it could say more about ALPN. 1) As an editorial comment ALPN is mentioned without expanding the acronym. The term is used, which doesn't seem to be defined anywhere other than the HTTP/3 specification (which might be a problem or not) 2) More substantial, there isn't really mention about any of the TLS or negotiation aspects of ALPN. We might see people try to offer multiple Application Protocols on the same UDP port, and using ALPN to select from them. Maybe this is more likely when QUIC can operate as both a stream-based and datagram-based protocol. 3) Related to 2, new application protocols over QUIC need an ALPN protocol identifier. This is distinct from the Alt-Svc discussion in Section 6; since other protocols won't use Alt-Svc, they might overlook things. The ALPN space is large but we might benefit from some text that gives people pointers on how to register the ALPN IDs they want to use before someone gets them. For reference, I started a list of protocols at URL Not all of those need formal registration but it is a nice illustration.
I'm unfortunately not coming up with some useful/actionable text here. Maybe NAME or NAME has some insight that could help?
It feels like the best way to incorporate this is to expand the "protocol doesn't imply port" discussion to also include "port doesn't imply protocol" before concluding with "not being able to safely make this inference is hard." has a first stab at this, though it doesn't cover as much as NAME first suggested. Feel free to expand on it.
Change:
10.1.  URIs <del> [1] https://github.com/abetterinternet/prio-documents/issues/22 </del> <ins> [1] https://github.com/abetterinternet/prio-documents/issues/102 [2] https://github.com/abetterinternet/prio-documents/issues/22 </ins>

Discussion:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .
Change:
described in response-token-single. When neither an access token nor key proof are used, this is an <del> unsecured request.  This type of used only for calls to the RS during a discovery phase as described in rs-request-without-token. </del> <ins> unsecured request.  This type of request is used only for calls to the RS during a discovery phase as described in rs-request- without-token. </ins> 7.1.

Discussion:
Minor typos
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit b2ce64bfa924bc30b24ea9301223156ec0eb8520 https://deploy-preview-204--gnap-core-protocol-editors-URL
within (and likely other sections), the property names are plural, but the text sometimes refers to the singular property names. This should be cleaned up to be consistent one way or another.
Change:
The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.5. This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I- D.ietf-oauth-signed-http-request section 4, with the following additional requirements: The "at" (access token) field MUST be omitted unless this method is being used in conjunction with an access token as in use- access-token.  [[ See issue #112 [47] ]] The "b" (body hash) field MUST be calculated and included, if the message includes an entity body (such as a PUT or PATCH request). All components of the URL MUST be calculated and included, including query parameters "q", path "p", and host "u". The "m" (method) field MUST be included In this example, the request message body is the following JSON object The JOSE header for the PoP token is the following: After calculating the hashes for the body, headers, and URL components, the JWS Payload is the following: This leads to the following HTTP message request: [[ See issue #113 [48] ]] The verifier MUST parse the JWS object of the PoP header.  The verifier MUST validate the signature of the header against the expected key of the signer.  The verifier MUST ensure that all required parts of the message are covered by the signature.  The verifier MUST ensure that all components of the signature contain correct values. </del> 8. GNAP provides a rich structure for describing the protected resources

Discussion:
remove OAuth DPoP binding. Described why on IETF mailing list: OAuth PoP: expired draft, due to be replaced with new draft based on HTTP Message Signatures. Also closing and
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: a47cdeabae554f3636d63a0ce8e0f8b52ff53693 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Removed autoindent in my editor to fix the issue
OAuth Proof of Possession (PoP): Editor's note: This is a stale draft from the OAuth working group, but it does at least provide some basic functionality for protecting HTTP messages with a signature. This work is likely to be subsumed by the general-purpose HTTP message signature mechanism in Section 8.5.
OAuth Proof of Possession (PoP): Editor's note: This is in contradiction to the referenced spec which makes this field mandatory.
Change:
RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168. <del> If the most recent ACK_FREQUENCY frame an endpoint has received from the peer has an "Ignore CE" value of "true" (0x01), receipt of a CE marked packet SHOULD NOT cause an endpoint to send an immediate acknowledgement.  The endpoint still sends an immediate acknowledgement if it would have for a non CE marked packet.  If an immediate acknowledgement is not sent, the CE marks are reported in the next acknowledgement. The Ignore-CE bit SHOULD NOT be set if the sender sets ECT(1) in its outgoing packets, such as with L4S, because it delays the congestion controller's ability to quickly respond to congestion. </del> 7.3. For performance reasons, an endpoint can receive incoming packets

Discussion:
With the last draft(-03), there is a change on ACKFREQUENCY frame format (Remove Ignore CE and Reordering Threshold ) may be need change minack_delay value for detect what frame format do you need to use for decode ?
I think we should change the minackdelay Transport Param codepoint, which is currently 0xff03de1a, maybe to 0xff04de1a.
yes, I also thought about this and then forgot to bring it up. Maybe we should even submit a new version with a different number right tomorrow.
Submitting and then revving the version SGTM. I can't see a reason not to bump the codepoint, so please merge my PR if you agree NAME
Following up on discussion in issue and . It is not clear if this signal is needed at all. CE should always be provided as soon as possible. Only follow-up CE in the same RTT might be deployed. However, this seem to be part of the ECN specification (e.g. as discussed for AccECN) and not necessarily in scope for this document, as it is not clear why a sender signal for this is needed.
Thanks for filing this, I'll plan to include this in slides for Philadelphia.
Discussion at IETF 114: Remove Ignore_CE; we can add a transport parameter (possible) if someone really wants this feature.
Change:
A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of RFC7252 (where an attacker would put a victim's <del> address in the source address of a CoAP request).  For this purpose, a server MAY ask a client to Echo its request to verify </del> <ins> address in the source address of a CoAP request).  The RECOMMENDED way to do this is to ask a client to Echo its request to verify </ins> its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server.

Discussion:
I take URL as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT. (It wasn't intended as an update, as the SHOULD mentioned there is just a copy of the original 7252 SHOULD and we "provide one way", but no objections from me either). Along that I'd offer concrete size numbers, and a note that this really needs piggy-backed responses. Unless objected to, I'd take this into the next version of ERT (as soon as I have processed any other pending comments if there still are any). In draft-ietf-core-echo-request-tag-URL, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure. draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing. The SHOULD in Section 2.4 item 3 is a bit hidden for my taste. My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior. There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated. Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation? If you have a position on this, please reply to the list (or to the chairs) by March 2nd. Grüße, Carsten
Change:
The field is an Item and its value is a non-negative Integer expressed in service-limit.  Parameters are not allowed. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served.

Discussion:
According to URL there is no need to specify that information.
This text appears in relation to Item fields. By their nature Items can only occur on one field line (the proper terminology, btw), so this requirement is extraneous, and should be removed.
... and it's also on RateLimit-Policy, even though that is a List field.
Change:
DATAGRAM frames contain the following fields: <del> A variable-length integer specifying the length of the datagram in bytes.  This field is present only when the LEN bit is set.  If the LEN bit is not set, the datagram data extends to the end of the QUIC packet.  Note that empty (i.e., zero-length) datagrams are allowed. </del> <ins> A variable-length integer specifying the length of the Datagram Data field in bytes.  This field is present only when the LEN bit is set to 1.  When the LEN bit is set to 0, the Datagram Data field extends to the end of the QUIC packet.  Note that empty (i.e., zero-length) datagrams are allowed. </ins> The bytes of the datagram to be delivered.

Discussion:
and a bit of editorializing of thee text to match RFC 9000.
If you're receptive to this suggestion I am happy to file a PR
Oh wow I hadn't realized that we never updated to the new style. A PR would be lovely please!
Change:
4.1. <del> This key indicates the set of supported protocols (SVCB Section 6.1). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </del> <ins> This key indicates the set of supported protocols (Section 6.1 of SVCB).  There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </ins> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the

Discussion:
The lack of quoting in some of the examples might make it harder to see what constitutes example and what is punctuation. Highlighting and fonts in the HTML rendering are subtle and not present in text renderings (any more). I've also changed some section references. I'm happy to split that off into a different change or use the form if you prefer that.
Change:
8.2.2. <del> When a message is sent in response to a message received, the application can use the Message Context of the received Message to construct a Message Context for the reply. By using the "replyMessageContext", the transport system is informed that the message to be sent is a response and can map the response to the same underlying transport connection or the stream from which the request was received.  The concept of Message Contexts is described in msg-ctx. 8.2.3. </del> Like all Actions in this interface, the Send Action is asynchronous. There are several Events that can be delivered in response to Sending a Message.  Exactly one Event (Sent, Expired, or SendError) will be

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media- types@iana.org on Sept 21, 2010.  A second request for all the types <del> was sent on October 31, 2016. </del> <ins> was sent on October 31, 2016.  Please change all instances of RFC- AAAA with the RFC number of this document. </ins> 12.3.1.

Discussion:
Alternatively we can have the same text 9 times instead of 8
Alexey confirmed in the CoRE session that this is OK, so let's go forward with this.
The IANA types review list explicitly wanted all of this repeated because they don't read the draft on the email and each type needs it's own email. It is insane. So I would not make this change. LGTM
Change:
avoid replay attacks on the protocol. Of the frames defined in QUIC-TRANSPORT, the STREAM, RESET_STREAM, <del> and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT as they carry application data.  Application data that is received in 0-RTT could cause an application at the server to process the data multiple times rather than just once.  Additional actions taken by a server as a result of processing replayed application data could have unwanted consequences.  A client therefore MUST NOT use 0-RTT for application data unless specifically requested by the application that is in use. </del> <ins> STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT as they carry application data.  Application data that is received in 0-RTT could cause an application at the server to process the data multiple times rather than just once.  Additional actions taken by a server as a result of processing replayed application data could have unwanted consequences.  A client therefore MUST NOT use 0-RTT for application data unless specifically requested by the application that is in use. </ins> An application protocol that uses QUIC MUST include a profile that defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to

Discussion:
So it could be unsafe for use in 0-RTT.
NAME said:
STOP_SENDING can be sent in 0-RTT. It should be in the list.
Change:
access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. <del> 6.3. </del> <ins> 5.2. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated credential would revoke the credential.  Revocation of the long term <del> private key that signs the delegated credential also implictly </del> <ins> private key that signs the delegated credential also implicitly </ins> revokes the delegated credential. <del> 6.4. </del> <ins> 5.3. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate

Discussion:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me
Change:
be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <del> 16.7. </del> <ins> 16.9. </ins> This document registers the "message/mls" MIME media type in order to allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?
Change:
Attackers could replay tokens to use servers as amplifiers in DDoS attacks.  To protect against such attacks, servers MUST ensure that replay of tokens is prevented or limited.  Servers SHOULD ensure that <del> tokens sent in Retry packets are only accepted for a short time. Tokens that are provided in NEW_TOKEN frames (frame-new-token) need to be valid for longer, but SHOULD NOT be accepted multiple times in a short period.  Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse. </del> <ins> tokens sent in Retry packets are only accepted for a short time, as they are returned immediately by clients.  Tokens that are provided in NEW_TOKEN frames (frame-new-token) need to be valid for longer, but SHOULD NOT be accepted multiple times.  Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse. </ins> 8.2.

Discussion:
They only need to be good for one RTT. Of course, the server doesn't really know what the RTT is, so this isn't something firm, and I don't want to explain ALL of that, but this should do.
Roman Danyliw said: