jiebi/CodeConvo huggingface dataset:
Change:
4.2. <del> Extremely limited loss and RTT measurement are possible by passive observation of QUIC traffic; see sec-rtt and sec-loss. </del> <ins> Limited loss measurement and detailed RTT measurement are possible by passive observation of QUIC traffic; see sec-rtt and sec-loss. </ins> 4.3.

Discussion:
This PR takes text from to explain the on-path use of the latency spin bit. It is the manageability draft companion of the new .
I don't think we want to merge this until we have consensus that the spin bit itself is merged?
NAME fbc8490 changes this to point to the experiment (quic-spin-exp), not to the protocol, and to be clear that it's an experiment. It also pretends the VEC doesn't exist, since quic-spin-exp does so as well. If the experiment merges into the protocol, then we update this draft to point to it; if not, then the text changes in a subsequent draft to omit in-flow RTT.
To further clarify, the draft was mentioning that there is a discussion about the spin bit before. This PR mainly only now points to the respective draft. I think it is far to have this pointer in there for now.
Well, as long as you are prepared to possibly remove this, fine
The nice thing about Internet-Drafts is that they are endlessly mutable. :)
Change:
An application server can voluntarily identify itself to a push service using the described technique.  This identification information can be used by the push service to attribute requests <del> that are made by the same application server to a single entity.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </del> <ins> that are made by the same application server to a single entity, and reduce the need for endpoint secrecy by being able to associate subscriptions with an application server.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </ins> 1.

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:
An application server can voluntarily identify itself to a push service using the described technique.  This identification information can be used by the push service to attribute requests <del> that are made by the same application server to a single entity.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </del> <ins> that are made by the same application server to a single entity, and reduce the need for endpoint secrecy by being able to associate subscriptions with an application server.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </ins> 1.

Discussion:
NAME can you check that this is all OK with you? I've made you an author :)
SG, thanks. The only difference with my PR seems to be removal of details, which I guess are too specific for the proposal phase.
Change:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the DTLS- SRTP parameters RFC5763 sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose different values. </del> <ins> However, not all parameters follow this rule; for example, the fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Discussion:
Originally raised by Christer Section 3.2 says: "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup" 1) I am not sure what "parameters" the text is referring to. If it¹s the fingerprint, I think the text should reference RFC 4572. 2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless explicitly indicated otherwise.
The parameters include a=setup and a=fingerprint. 5763 seems like it covers both.
NAME thoughts?
Authors believe this text is fine. NAME please send us a PR with the specific change you want if you disagree.
NAME said in email: certificate the local side will use in DTLS setup". >So, I would suggest to replace: “However, not all parameters follow this rule; for example, the DTLS- SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive;” >…with: “However, not all parameters follow this rule; for example, the fingerprints sent to a remote party are calculated based on the local certificate(s) offered;” >If you agree with that understanding, I’m happy to submit a pull request.
OK, I now see what you are saying, and I think the text you propose looks reasonable. Thanks for offering to submit a PR!
[waiting on PR from NAME
It seems like I don't have rights to submit new branches (needed for the PR).
cd4u: fork the repo and push the branch to your fork, then submit the PR from there.
PR created: URL
Fixed by
Change:
Signature Algorithms ("signature_algorithms"; signature- algorithms) <ins> Signature Algorithms Certificate ("signature_algorithms_cert"; signature-algorithms) </ins> Negotiated Groups ("supported_groups"; negotiated-groups) Key Share ("key_share"; key-share)

Discussion:
In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.
Change:
be informed in case sent data was retransmitted more often than a certain threshold.  The default is to Ignore this option. <del> 5.2.15. </del> <ins> 5.2.16. </ins> Name: :soft-error-notify

Discussion:
Address
API should allow a preconnection property to specify if a private (IPv6) address is preferred. Outbound connections should prefer this. Listeners should avoid this.
Thank you! I was really missing this one .LGTM!
Change:
special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure. <del> As the available bandwidth has increased, and as processors an other </del> <ins> As the available bandwidth has increased, and as processors and other </ins> hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware.

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt
Change:
Queries: <del> Note: This ordering of the results for the "$..[*]" and "$..*" </del> <ins> Note: The ordering of the results for the "$..[*]" and "$..*" </ins> examples above is not guaranteed, except that: <del> "{"o": {"j": 1, "k": 2}, "a": [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </del> "{"j": 1, "k": 2}" must appear before "1" and "2", <del> "[5, 3]" must appear before "5" and "3", and </del> <ins> "[5, 3, [{"j": 4}]]" must appear before "5", "3", and "[{"j": 4}]", "5" must appear before "3" which must appear before "[{"j": 4}]", "[{"j": 4}]" must appear before "{"j": 4}", and </ins> <del> "5" must appear before "3". </del> <ins> "{"j": 4}" must appear before "4". </ins> 3.5.8.

Discussion:
Exclude the node itself Define the term "descendants" more precisely Define the descendant selector semantics more thoroughly Fixes: URL
I would consider adding two additional examples: given: results in: - and results in: - ] ]
I extended the existing example attempting to exhibit the same points as the example above.
Looks good, thanks!
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.
I haven't checked the examples, but I like the narrative changes.
Change:
of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. <del> Each range MUST be delivered in a single packet. </del> <ins> Each range MUST be delivered in a single UDP datagram. </ins> When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
client and how the communication between client and AS is protected, fulfilling the requirements specified in oauthProfile. <del> The default name of this endpoint in an url-path is '/token', however implementations are not required to use this name and can define their own instead. </del> <ins> The default name of this endpoint in an url-path SHOULD be '/token'. However, implementations are not required to use this name and can define their own instead. </ins> The figures of this section use CBOR diagnostic notation without the integer abbreviations for the parameters or their values for

Discussion:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged
Change:
6.1. <del> To offer ECH, the client first chooses a suitable ECH configuration. To determine if a given "ECHConfig" is suitable, it checks that it supports the KEM algorithm identified by "ECHConfig.contents.kem_id", at least one KDF/AEAD algorithm identified by "ECHConfig.contents.cipher_suites", and the version of ECH indicated by "ECHConfig.contents.version".  Once a suitable configuration is found, the client selects the cipher suite it will use for encryption.  It MUST NOT choose a cipher suite or version not </del> <ins> To offer ECH, the client first chooses a suitable ECHConfig from the server's ECHConfigList.  To determine if a given "ECHConfig" is suitable, it checks that it supports the KEM algorithm identified by "ECHConfig.contents.kem_id", at least one KDF/AEAD algorithm identified by "ECHConfig.contents.cipher_suites", and the version of ECH indicated by "ECHConfig.contents.version".  Once a suitable configuration is found, the client selects the cipher suite it will use for encryption.  It MUST NOT choose a cipher suite or version not </ins> advertised by the configuration.  If no compatible configuration is found, then the client SHOULD proceed as described in grease-ech.

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status <del> code 200 whose body consists of TokenResponse, with the content type set as "application/private-token-response". </del> <ins> code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response". </ins> 6.3. Upon receipt, the Client handles the response and, if successful, <del> processes the body as follows: </del> <ins> processes the content as follows: </ins> The rsabssa_finalize function is defined in BLINDRSA, Section 5.1.3.. If this succeeds, the Client then constructs a Token as described in

Discussion:
... I think. I'm double checking to see if there is any other improper HTTP usage.
The Issuance protocol depends on HTTP, so I'd expect this to be cited. Then we get into the HTTP terminology alignment game. For example, where the document says something like should be substituted for as per URL
Change:
Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period.  An attacker who <del> compromises the private key of a delegated credential can act as a man-in-the-middle until the delegated credential expires.  However, they cannot create new delegated credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other.  The secrecy of the delegated credential's private key is thus important and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </del> <ins> compromises the private key of a delegated credential can impersonate the compromised party in new TLS connections until the delegated credential expires. However, they cannot create new delegated credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other.  The secrecy of the delegated credential's private key is thus important and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </ins> 7.2.

Discussion:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.
Change:
Issue credentials to clients that attest to bindings between identities and signature key pairs <del> Enable a group member to verify that a credential presented by another member is valid with respect to a reference identifier </del> <ins> Enable a client to verify that a credential presented by another client is valid with respect to a reference identifier </ins> Enable a group member to verify that a credential represents the <del> same application-level device as another credential </del> <ins> same application-level device as another credential when possible </ins> A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key

Discussion:
This PR pulls in the CAP theorem-related discussion from URL which is a more helpful way to frame DS design.
Change:
the signature computation comprises all of the fields except for the signature field. <del> KeyPackage objects MUST contain at least three extensions, one of type "supported_versions", one of type "supported_ciphersuites", and one of type "lifetime".  The "supported_versions" and "supported_ciphersuites" extensions allow MLS session establishment to be safe from downgrade attacks on these two parameters (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> KeyPackage objects MUST contain at least two extensions, one of type "capabilities", and one of type "lifetime".  The "capabilities" extension allow MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> As the "KeyPackage" is a structure which is stored in the Ratchet Tree and updated depending on the evolution of this tree, each

Discussion:
This PR makes a few minor fixes to extensions: Coalesces and into a single extension Adds a list of supported extensions in parallel with the versions and ciphersuites Adds a missing value to the IANA table for the extension
Change:
In addition, the signature algorithm MUST be compatible with the key in the sender's end-entity certificate.  RSA signatures MUST <del> use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS- v1_5 algorithms appear in "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify.  (Note that rsa_pkcs1_sha1 and dsa_sha1, the only defined SHA-1 signature </del> <ins> use an RSASSA-PSS algorithm, regardless of whether RSASSA- PKCS1-v1_5 algorithms appear in "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify.  (Note that rsa_pkcs1_sha1 and dsa_sha1, the only defined SHA-1 signature </ins> algorithms, are undefined for CertificateVerify signatures.) Note: When used with non-certificate-based handshakes (e.g., PSK),

Discussion:
RFC 3447 refers to it as RSASSA-PKCS1-v15, not RSASSA-PKCS-v15.
Change:
4. <del> It is necessary to limit the amount of data that a receiver could buffer, to prevent a fast sender from overwhelming a slow receiver, or to prevent a malicious sender from consuming a large amount of memory at a receiver.  To enable a receiver to limit memory commitment to a connection and to apply back pressure on the sender, streams are flow controlled both individually and as an aggregate.  A QUIC receiver controls the maximum amount of data the sender can send on a stream at any time, as described in data-flow-control and fc- credit. </del> <ins> Receivers need to limit the amount of data that they are required to buffer, in order to prevent a fast sender from overwhelming them or a malicious sender from consuming a large amount of memory.  To enable a receiver to limit memory commitments for a connection, streams are flow controlled both individually and across a connection as a whole. A QUIC receiver controls the maximum amount of data the sender can send on a stream as well as across all streams at any time, as described in data-flow-control and fc-credit. </ins> Similarly, to limit concurrency within a connection, a QUIC endpoint controls the maximum cumulative number of streams that its peer can

Discussion:
Barry Leiba said:
receiver/client is an invalid comparison here, so this is a bit of a confusing question. The point is to ensure that a receiver can limit what space it commits for buffering.
With the suggestions, this is a fine, if small, improvement.