jiebi/CodeConvo huggingface dataset:
Change:
If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server <del> delete the authorization.  The client makes this request by sending a POST request to the authorization URI containing a payload in the same format as in deleting-an-account.  The only difference is that the value of the "resource" field is "authz". The server MUST perform the same validity checks as in deleting-an- account and reject the request if they fail.  If the server deletes the account then it MUST send a response with a 200 (OK) status code and an empty body. </del> <ins> deactivate each authorization associated with that identifier. The server MUST verify that the request is signed by the account key corresponding to the account that owns the authorization.  If the server accepts the deactivation, it should reply with a 200 (OK) status code and the current contents of the registration object. The server MUST NOT treat deactivated authorization objects as sufficient for issuing certificates. </ins> 6.5.

Discussion:
This simplifies both the spec and the implementation, and does not attempt to impose specific data retention policy on the CA.
I don't really agree about that one. Why not delete completely the data instead of deactivating? Why shouldn't a user be able to request full deletion and no retention of any of their account data?
Nothing in this change prevents CAs from choosing to delete account data immediately upon deactivation, but the spec should not try to dictate policy.
I think this PR is fine in principal, but I have some minor concerns: If we're going to use the field, we should prefer to use the values that are already there, namely and . Do you think there's a semantic difference between that and what you're proposing? Your edits remove the guidance on what the server should return from these requests. Please add that back in. It occurs to me looking at this that the first version of authz deletion should have specified that the server MUST verify that the account is the owner of the authz before allowing it to deactivate the authz. Could you please add that while you're editing here?
Done.
Change:
lists each desired encoding, and no "recv" simulcast stream description.  The "m=" section will also include an "a=rid" attribute for each encoding, as specified in RFC8851; the use of Restriction <del> Identifiers (RIDs) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </del> <ins> Identifiers (RIDs, also called rid-ids or RtpStreamIds) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </ins> 3.8.

Discussion:
This also adds in a sentence about using the MID header extension in outgoing streams, which was previously omitted despite there being a corresponding sentence for incoming streams.
The comment "[rfced] Please let us know if any changes are needed for the..." should also be removed.
AUTH48 on this document started with sixty [rfced] questions sent to the authors (NAME NAME NAME 2020 July 7. These questions were added as GitHub issues through . Follow on issues were created (in particular, splitting issues and ) to isolate some of the questions and to review normative text (). When PR is merged, all AUTH48 [rfced] questions will have been addressed, but there are some remaining XML comments that need to be removed.
This is sort of nuts but LGTM
Change:
ACME Order Object Fields (iana-order) <del> ACME Error Codes (iana-error) </del> <ins> ACME Error Types (iana-error) </ins> ACME Resource Types (iana-resource)

Discussion:
Usage of is slightly confusing when we are not using int-enumerated error codes. RFC 7807 also refers to the problem document error types as and the field is called so this seems to make the most sense.
Change:
Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the <del> remote peer can know whether a stream has been partially processed or not.  For example, if an HTTP client sends a POST at the same time </del> <ins> remote peer can know whether a request has been partially processed or not.  For example, if an HTTP client sends a POST at the same time </ins> that a server closes a QUIC connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on.

Discussion:
This change sounds good to me, but to make sure I understand: is the only purpose of this change to split HTTPREQUESTCANCELLED in two; client to server stays HTTPREQUESTCANCELLED and server to client now becomes HTTPREQUESTREJECTED? And is the goal to add clarity when parsing connection logs later?
NAME basically. In the previous text, CANCELLED had specific semantics when sent server->client. However, with the change to make RESETSTREAM reflect back the error code in STOPSENDING, the client->server STOPSENDING(CANCELLED) would provoke a RESETSTREAM(CANCELLED) in the server->client direction with that error code that didn't necessarily match those semantics. Hence the split -- one code has specific semantics when sent by a server, and clients are instructed to use the other code. (I would prohibit clients from sending it, but if the server sends a STOP_SENDING, the client would reflect it back and violate the prohibition, so....)
Change:
others may not have this property. Issuer identity.  Tokens identify which Issuers are trusted for a <del> given issuance protocol.  The selected Issuer transitively determines what types of attestation the Origin is willing to accept.  For example, if a given Issuer "issuer.example" has two trusted Attesters, then any Origin choosing "issuer.example" as its Issuer is willing to accept attestation checks done by either of these two Attesters. </del> <ins> given issuance protocol.  Each Issuer, in turn, determines which Attesters it is willing to accept in the issuance protocol.  This means that if an Origin origin.example accepts tokens issued by Issuer issuer.example, and that Issuer in turn accepts different types of attestation from more than one trusted Attester, then a Client may use either of these trusted Attesters to issue and redeem tokens for origin.example.  However, origin.example neither explicitly specifies nor learns the Attesters or their attestation formats used for token issuance. </ins> Redemption context.  Tokens can be bound to a given redemption context, which influences a client's ability to pre-fetch and

Discussion:
cc NAME
I found this sentence hard to interpret: both because of the use "transitive" and because, AIUI, the Origin does not directly accept attestations at all. I tried to be a bit more explicit in this phrasing:
Good clarification! Please check out the linked PR where I applied a variant of your suggested text.
Change:
HpkeConfig hpke-config: "application/dap-hpke-config" <del> Report upload-request: "message/dap-report" </del> <ins> Report upload-request: "application/dap-report" </ins> <del> AggregateInitializeReq collect-flow: "message/dap-aggregate- </del> <ins> AggregateInitializeReq collect-flow: "application/dap-aggregate- </ins> initialize-req" <del> AggregateInitializeResp collect-flow: "message/dap-aggregate- </del> <ins> AggregateInitializeResp collect-flow: "application/dap-aggregate- </ins> initialize-resp" <del> AggregateContinueReq collect-flow: "message/dap-aggregate- </del> <ins> AggregateContinueReq collect-flow: "application/dap-aggregate- </ins> continue-req" <del> AggregateContinueResp collect-flow: "message/dap-aggregate- </del> <ins> AggregateContinueResp collect-flow: "application/dap-aggregate- </ins> continue-resp" <del> AggregateShareReq collect-flow: "message/dap-aggregate-share-req" </del> <ins> AggregateShareReq collect-flow: "application/dap-aggregate-share- req" </ins> <del> AggregateShareResp collect-flow: "message/dap-aggregate-share- </del> <ins> AggregateShareResp collect-flow: "application/dap-aggregate-share- </ins> resp" <del> CollectReq collect-flow: "message/dap-collect-req" </del> <ins> CollectReq collect-flow: "application/dap-collect-req" </ins> <del> CollectResp collect-flow: "message/dap-collect-resp" </del> <ins> CollectResp collect-flow: "application/dap-collect-resp" </ins> The definition for each media type is in the following subsections.

Discussion:
(opinionatedly: please see discussion on that issue)
Currently, DAP uses the following media types (defined in section 7.1): Note that the first uses the top-level type, while the remainder use the top-level type. For consistency, I suggest we use the same top-level type for all messages. Which type is more appropriate? Per : is for "either uninterpreted binary data or information to be processed by an application" is for "an encapsulated message"; all of the motivating examples (see section 5.2) are around encaspulating one message format inside another, or fragmenting a message into multiple chunks. provides further guidance that "multipart and message are composite types; that is, they provide a means of encapsulating zero or more objects, each one a separate media type." Given that DAP messages are not a method of encapsulating a message of a different type, I suggest that is the more appropriate top-level type to use. This is also supported by the rather large number of media types vs the relatively tiny number of media types in . (this issue fell out of discussion on URL)
Agreed, seems better.
The types were chosen in PR on a tentative basis, and marked with "OPEN ISSUE: Solicit review of these allocations from domain experts." Based on the encapsulation reasoning, I agree that be most appropriate for our media types.
As a non-HTTP expert, I agree with the rationale. Thanks, NAME based on the text quoted by NAME in the linked issue. It would be great to get feedback from folks who have more experience working on HTTP-based applications.
Change:
preference. Clients may offer an arbitrary number of ClientKeyShareOffer values, <del> each representing a single set of key agreement parameters; for </del> <ins> each representing a single set of key exchange parameters; for </ins> instance a client might offer shares for several elliptic curves or multiple integer DH groups.  The shares for each ClientKeyShareOffer MUST by generated independently.  Clients MUST NOT offer multiple

Discussion:
NAME please confirm this matches consensus
Now that we are removing static RSA cipher suites, we need a new MTI cipher suite.
From Sean's mail o Symmetric: MUST AES-GCM 128 [SHOULD ChaCha20-Poly1305] o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 [SHOULD 25519] o Signature: MUST ECDSA P-256 MUST RSA
Dear Mr. NAME currently I'm very interested in studying non-repudiation, then I found S-HTTP (RFC 2660) that offer non-repudiation security service. I also found that AS2 (RFC 4130) also offers this kind of service, but then I wonder why non-repudiation service is not becoming ubiquotus? Why AEAD replace HMAC, does hash function is too heavy, or hash is more appropriate for digital signature world? Thanks
Change:
cookies, though the push service would not be able to offload any state as a result. <ins> 2.2. The public key or otherwise public token offered by the application service to the push service may also be used to associate a subscription with the application server that can prove possession of the private counterpart. Subscription association reduces the reliance on endpoint secrecy by requiring this proof to be presented when requesting delivery of a push message.  This can provide an additional level of security in a situation where the application server may suffer a data leak. 2.2.1. The user agent may include the public token of the application server to associate the subscription with when creating a subscription, when developer has made the association token available.  For example, the Web Push API API could enable the public token of the application server to associate the subscription with in the "association" field of the PushSubscriptionOptions dictionary. The URL-safe base-64 encoded RFC4648 representation of the token may be included by the user agent by including a Crypto-Key header in the request to create a new subscription. As an extension, accepting multiple keys to be specified in the Crypto-Key header when creating a subscription would allow a subscription to be associated with multiple application servers. This would require more state to be maintained by the push service for each subscription. 2.2.2. When a subscription has been associated with an application server, the request for push message delivery must include proof of possession of the private counterpart of the token that was used when creating the subscription. If the application server cannot satisfy this requirement, the application server must reject the delivery and generate a 401 (Unauthorized) status code. </ins> 3. This document has no IANA actions (yet).

Discussion:
I welcome any level of feedback. One specific question is how to specify the association token when creating a new subscription. I used my beloved header, but the token may be something other than a DH public value. Do you know of appropriate headers that could be used for this purpose?
I think that this is pretty good. I would want to tighten this a little more, but until we decide on an approach, we're somewhat constrained in what we can say.
My understanding is that this is just a proposal, the formal draft (either separately or merged with the main draft) would not mention the alternative options either, right?
Yeah, this is just input for discussion. If we decide on an approach, it's probably something we can merge into one of the other drafts. Or, it could remain separate and we could either remove the alternatives or move them to an appendix.
Change:
request with a failure, or if the datagrams are received by the proxy before the request. <del> Endpoints MUST NOT send HTTP Datagrams with payloads longer than 65527 using Context ID zero.  An endpoint that receives a DATAGRAM capsule using Context ID zero whose payload is longer than 65527 MUST </del> <ins> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527 using Context ID zero.  An endpoint that receives a DATAGRAM capsule using Context ID zero whose Payload field is longer than 65527 MUST </ins> abort the stream.  If a proxy knows it can only send out UDP packets of a certain length due to its underlying link MTU, it SHOULD discard <del> incoming DATAGRAM capsules using Context ID zero whose payload is longer than that limit without buffering the capsule contents. </del> <ins> incoming DATAGRAM capsules using Context ID zero whose Payload field is longer than that limit without buffering the capsule contents. </ins> 6.

Discussion:
The last paragraph of section 5, considers payload length There's a small chance for confusion here, because the DATAGRAM capsule format has a field and has a field. Consider therefore explicitly illustrating the maths that is required to determine the payload for which your 65527 limit MUST apply. I.e. this would be calculated by looking at the Capsule's length value and subtracting the encoded length of the Context ID field. (or whatever the answer is, in case I got it wrong)
Change:
in CBOR as a 'bstr' if present and the value 'null' if there is no data.  The contents of the protected field is a CBOR map of the protected data names and values.  The map is CBOR encoded before <del> placing it into the bstr. </del> <ins> placing it into the bstr.  Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. </ins> contains information about the plain text that is not integrity protected.  If there are no field, then the value 'null' is used. <ins> Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. </ins> contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV,

Discussion:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
Change:
registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.4. </del> <ins> 6.3.1. </ins> A client may wish to change the public key that is associated with a registration, e.g., in order to mitigate the risk of key compromise.

Discussion:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).
Change:
packet.  The client IP address is 16 octets.  If an IPv4 address, the last 12 octets are zeroes. <del> date-time: The date-time string is a total of 20 octets and encodes the time the token was generated.  The format of date-time is described in Section 5.6 of RFC3339.  This ASCII field MUST use the "Z" character for time-offset. </del> <ins> Timestamp: The timestamp is a 64-bit integer, in network order, that expresses the number of seconds in POSIX time (see Sec. 4.16 of TIME_T). </ins> Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  Opaque data

Discussion:
As the draft describes: 'The date-time string is a total of 20 octets and encodes the time the token was generated. The format of date-time is described in Section 5.6 of [RFC3339].' this needs 20 octets in ascii, may be the unix time which is the the number of seconds since the Unix epoch in 8 octets is a better choice in transmission and computing ?
NAME have a look at the PR, please
Change:
receiver within the maximum ack delay and are called ack-eliciting packets. <ins> Packets are considered in-flight when they are ack-eliciting or contain a PADDING frame, and they have been sent but are not acknowledged, declared lost, or abandoned along with old keys. </ins> 3. All transmissions in QUIC are sent with a packet-level header, which

Discussion:
ACK-only was only even used in the definition part and in-flight can also be defined using ack-eliciting.
I just realised that padding is the "complicating" thing here. I still don't think we need to define "act-only" just for that but can rather be explicit about padding frames because otherwise this is easy to miss (as I did initially).
While the defined term is not used elsewhere, the phrases "Packets containing only ACK frames" and "Packets only containing ACK frames" are used. We should either eliminate the definition or explicitly use the defined term in those places.
Of Mike's options, I think that this makes sense. Fewer defined terms means lower fixed cognitive load when reading this. Less jargon = good.I re-read the other spots NAME mentioned and I believe the text is still correct, so I'm going to accept this. Thanks for the simplification.
Change:
will perform incompatible version negotiation instead, see incompat- vn. <del> For the duration of the compatible version negotiation process, clients MUST use the same 5-tuple (source and destination IP addresses and UDP port numbers).  During that time, clients MUST also use the same Destination Connection ID, except if the server explicitly instructs the client to use a different Destination Connection ID (for example, a QUIC version 1 server can accomplish this by sending an INITIAL packet with a Source Connection ID that differed from the client's Destination Connection ID).  This allows load balancers to ensure that packets for a given connection are routed to the same server. </del> <ins> Note that, after the first flight is converted to the negotiated version, the handshake completes in the negotiated version.  The entire handshake (including the converted first flight) needs to conform to the rules of the negotiated version.  For instance, if the negotiated version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight. </ins> 5.

Discussion:
indicates that the address tuple used for the first flight remain stable. This is probably OK, but I think that this is unnecessary. What seems particularly risky here is anticipating the rules about connection IDs that might apply to both versions: My preference here is to drop this text entirely and leave it to the negotiated version to specify these rules. Once you have performed whatever mapping/transformation that is defined, then the first flight complies with the requirements of the negotiated version and you are subject to the rules of that version. Trying to manage the intersection of both sets of rules is complicated. Better not to chase down that rabbit hole (I've been there). FWIW, I fully expect v2 to also specify address tuple stability during the handshake. However, if it does not and a client can send a v2 first flight on multiple tuples (leaving aside the implausibility of expecting those datagrams to arrive at the same place), then that won't be naturally compatible with v1 and you won't be able to start with v2 in that way and expect to be able to negotiate v1 out of that. This is no different than your new, optional frame example.
I think we need to state something about 5-tuple stability here, because if version A requires 5-tuple stability and version B requires 5-tuple stability, neither of those documents specifies that the two halves of the handshake (the first half using A, and the second half using B) need 5-tuple stability between them.
I don't think that you need to say anything about that specifically. You might use it as an example in a sentence like:
Fair enough, that works for me.
Change:
IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 <del> bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths will be able to support QUIC. </del> <ins> bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or

Discussion:
NAME said: >14 "Thus, modern IPv4 and all IPv6 network paths will be able to support QUIC." Generally true, but should be qualified for the presence of arbitrary numbers of tunnels.
This is not one that I have an answer to currently. We could just wave this away as Martin suggests, but I'm not sure that is best. What do tunneling protocols say about ensuring the IPv6 minimum MTU?
I don't know what the IETF tunneling protocols say about MTU, but I don't expect them to violate IPv6 minimum MTU (someone should correct me if I'm wrong). The problem here might not be about what allowances we make for tunneling -- I don't want to create a list of exceptions in this document -- but about wording. I propose changing "will be able to support" to "are expected to support". As long as we are not making assumptions that violate permissions afforded by spec or practice, I think we're good.
Thanks. This is weaker, but truer.