jiebi/CodeConvo huggingface dataset:
Change:
The Hash function used by HKDF is the ciphersuite hash algorithm. Hash.length is its output length in bytes.  In the below diagram: <del> HKDF-Extract takes its Salt argument from the top and its IKM </del> <ins> HKDF-Extract takes its salt argument from the top and its IKM </ins> argument from the left Derive-Secret takes its Secret argument from the incoming arrow

Discussion:
I'm approving these changes given the current state of the document, but I filed because the KDF stuff is broken. Please make HPKE a normative reference (since it's required to implement). Since it's an Internet-Draft, you don't need to add it to the references section, you can just reference it directly as and the Markdown processor will add the reference. (Change the to for an informative reference.)
Change:
in either of these parameters need not be fatal. The server indicates its selected parameters in the ServerHello as <del> follows: If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key.  If PSK is not being used, then (EC)DHE and certificate-based authentication are always used.  When (EC)DHE is in use, the server will also provide a "key_share" extension.  When authenticating via a certificate, the server will send an empty "signature_algorithnms" extension in the ServerHello and will subsequently send Certificate (certificate) and CertificateVerify (certificate-verify) messages. If the server is unable to negotiate a supported set of parameters, </del> <ins> follows: If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key. If PSK is not being used, then (EC)DHE and certificate-based authentication are always used. When (EC)DHE is in use, the server will also provide a "key_share" extension. When authenticating via a certificate, the server will send an empty "signature_algorithnms" extension in the ServerHello and will subsequently send Certificate (certificate) and CertificateVerify (certificate-verify) messages. If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), </ins> it MUST return a "handshake_failure" alert and close the connection. 4.1.2.

Discussion:
I took this bit out of the 1st paragraph: -If any of these parameters has no overlap between the -client and server parameters, then the handshake -will fail. and moved it to the last para in the section because it doesn't say what alert value is to be returned, there's not something similar in the following paragraph that describes the PSK failure case, and finally the full failure text is included in the final paragraph. Basically, I just move the failure case to the final paragraph. An alternate would be to copy the failure to the PSK paragraph and include the which alert to return in the non-PSK para.
Change:
important when quota-policies use a large "time-window". Under certain conditions, a server MAY artificially lower "RateLimit" <del> field values between subsequent requests, eg. to respond to Denial of Service attacks or in case of resource saturation. </del> <ins> field values between subsequent requests, e.g. to respond to Denial of Service attacks or in case of resource saturation. </ins> Servers usually establish whether the request is in-quota before creating a response, so the RateLimit field values should be already

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client <del> CertificateVerify messages).  Within the handshake, this field MUST be empty. </del> <ins> CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges described in Section 4.5.2. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

Discussion:
I wanted to clarify in what part of the exchange the certificaterequestcontext field has a zero length.
Change:
multiple entities to manage certificates). Authorization resources are created by the server in response to <del> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </del> <ins> newOrder or newAuthz requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending

Discussion:
"newAuthorization" -> "newAuthz" Reverted the indentation on the IANA considerations since that resulted in the wrong XML
Change:
characteristics and habits of the user of an application. Of course any communication over a network reveals usage <del> characteristics, as all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </del> <ins> characteristics, because all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </ins> information is visible, potentially in clear text, and which other entities can access it.  In most cases, information provided for protocol and path selection should not directly translate to

Discussion:
The guidance applies to any connectionless transport.
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
LGTM
Change:
5.1.2. For media m= sections, JSEP implementations MUST support the <del> "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate </del> <ins> "UDP/TLS/RTP/SAVPF" profile specified in RFC5764, and MUST indicate </ins> this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they <del> produce in an offer.  Because ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </del> <ins> produce in an offer.  Although these profiles are formally associated with UDP, ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, even when advertising a UDP profile. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of

Discussion:
Slightly more than minor maybe: The first paragraph of 5.1.2 has at least a reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's in RFC5764. Assuming that this is only a reference error, then the last sentence seems like a stray. It doesn't seem to be in the right context ("this advertisement" doesn't cast back to the discussion of the two profiles above it, which are both UDP only). Please clarify the sentence, giving it the right context, or remove it.
This text is correct. The point is we are saying "advertise UDP but we can do TCP or UDP". We can try to rewrite.
LGTM
Change:
steps.  The creation of the EKTField MUST precede the normal SRTP packet processing. <del> The computed value of the FullEKTField is appended to the SRTP packet. </del> <ins> The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload. </ins> When a packet is sent with the ShortEKTField, the ShortEKFField is simply appended to the packet. Outbound packets SHOULD continue to use the old SRTP Master Key for <del> 250 ms after sending any new key.  This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key. </del> <ins> 250 ms after sending any new key in a FullEKTField value.  This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key.  (The specific value of 250ms is chosen to represent a reasonable upper bound on the amount of latency and jitter that is tolerable in a real-time context.) </ins> 4.3.2.

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
separate module that will provide authentication, using EAP for example. <del> SRTP </del> IKEv2 tcpcrypt

Discussion:
This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.
Change:
RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. <ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m= section. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only m= sections MUST NOT contain any

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
acknowledgments will cause undesirable bursts of data into the network. <ins> 9.4. To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends or it can simply send an IMMEDIATE_ACK frame, which is a non-probing frame. An endpoint's congestion controller and RTT estimator are reset upon confirmation of migration (Section 9.4 of QUIC-TRANSPORT), which can impact the number of acknowledgements received after migration.  An endpoint that has sent an ACK_FREQUENCY frame earlier in the connection SHOULD update and send a new ACK_FREQUENCY frame immediately upon confirmation of connection migration. 9.5. A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </ins> 10. TBD.

Discussion:
The draft doesn't mention anything about ACK frequency and connection migration. What should we do, for example, when a client has migrated and now sends a PING to force the server to use a new path? Should it send PING+IMMEDIATE_ACK?
That seems sensible. Mind writing a PR?
There's nothing odd about an immediate ACK! Perhaps the text should start by saying that the spec allows a receiver to do this anyway? However, the current text doesn't explain why the Immediate ACK might be useful. I could see three places that might benefit from an IMMEDIATE_ACK: Two cases relevant to SCTP [RFC7053] are: When the rate of transmission was very low and packets might be lost and not detected (something not uncommon in some SCTP uses); as an alternative to detect connectivity failure and trigger path failover. I'm not sure how important these specific cases are for QUIC, because the discussion at the time in TSVWG appeared to centre around use for signalling traffic? There could also be real opportunity to use this to get more precise timing/congestion information. A set of per-packet ACKs might be useful while a CC is probing to confirm available capacity, etc. Have I missed a killer application for the method - it would be helpful to me to understand /some example for how the WG think this could be used. (aside: I am actually uncertain whether this would really be a good change to TCP, especially with the heterogeniety of TCP middleboxes and senders,... that's another story, but I'd think it might be nice to not rely on draft-gomez-tcpm-ack-pull as a reference. I could suggest RFC7053, where people might recall there was quite some discussion in TSVWG about whether SCTP would benefit from being able to trigger an immediate response.)
We use an immediate ACK to support CC by delayed ACKs.
URL adds two use cases that uses IMMEDIATE_ACK.
These changes both look good to me.
Change:
In all cases, attestation key provisioning must ensure that only attestation key material that is generated by a valid Endorser is <del> established in Attesters. </del> <ins> established in Attesters.  For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. </ins> 12.2.

Discussion:
This is the portion of the complete review that contains minor/editorial changes aggregated in a single PR and various commits as discussed in the last editor meeting.
Are you sure that making Composite Device a term isn't a better idea?
I agree with that. There are also some other terms that I would capitalize. But this is the editorial part of the changes so I stuck with the groups consensus. Could you open an issue on "terms you want to capitalize"?
When I ask github to render the diff, it says that it can not. ("Oh my") it says. I wonder if there is an error in the markdown?
Change:
this request and its signature, and indicates the old key holder's assent to the rollover request. <del> To create this request object, the client first constructs a key- change object describing the account to be updated and its account </del> <ins> To create this request object, the client first constructs a keyChange object describing the account to be updated and its account </ins> key: The URL for the account being modified.  The content of this field

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
N/A <del> A unidirectional stream header contained an unknown stream type. </del> <ins> The endpoint detected that its peer created a stream that it will not accept. </ins> <del> A unidirectional stream type was used more times than is permitted by that type. </del> <ins> N/A </ins> A stream required by the connection was closed or reset. <del> A unidirectional stream type was used by a peer which is not permitted to do so. </del> <ins> N/A </ins> The remainder of the client's request is not needed to produce a response.  For use in STOP_SENDING only.

Discussion:
There are presently several kinds of very similar error when creating streams: HTTPUNKNOWNSTREAMTYPE MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer. It is not a connection error. HTTPWRONGSTREAMCOUNT MUST be used if a peer tries to open more than one critical stream (control, QPACK). Connection error. HTTPWRONGSTREAMDIRECTION MUST be used if a client tries to open a push stream. More generally this could be used if a peer attempts to open a stream type that is not allowed to, but push is the only example today. Connection error. The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION. The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop. PS. The eagle eyes will notice I omitted the HTTPDUPLICATE_PUSH creation error. This is on the chopping block in . I class it differently because it is about parsing information after the stream type.
Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream? At the moment the designated error code is HTTPGENERALPROTOCOLERROR, but STREAMCREATIONERROR might be a better fit. Or if we are not going to use STREAMCREATIONERROR for server-initiated bidirectional streams, I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion.
This relates to some earlier discussion on URL and its now-merged PR URL We only recently added text to specify the use of HTTPGENERALPROTOCOLERROR in this case, I think it fits to modify this to STREAMCREATION_ERROR.
Changed in URL
Change:
included for the defined namespaces in addressing and discovery_eo . */ <del> 8. </del> <ins> 9. </ins> The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
The following metadata items are defined, all of which are OPTIONAL: <del> A string containing a URI identifying the current terms of service. </del> <ins> A URI identifying the current terms of service. An HTTP or HTTPS URL locating a website providing more information about the ACME server. </ins> <del> String containing an HTTP or HTTPS URL locating a website providing more information about the ACME server. </del> <ins> Each string in this array MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </ins> <del> If present, MUST be an array of strings.  Each string MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </del> <ins> An HTTP or HTTPS URI indicating a website where a user can perform account-managment functions.  For example, this website might allow a user to associate a new account key pair to an account by proving possession of a registered contact, in the event that the user loses the account private key. </ins> Clients access the directory by sending a GET request to the directory URI.

Discussion:
We already removed token-based account recovery; this PR removes contact-based recovery. It was already almost entirely unspecified, due to it being a process that primarily takes place outside of ACME. Removing account recovery from ACME simplifies both the protocol and the security considerations. As an alternative, this PR adds an field to the dictionary in the directory, which the CA can use to expose account management functions such as recovery. But you can also imagine using this for more sophisticated account management functions, like associating an ACME account with some other account in a different system.
(Also threw in some editorial corrections, sorry)
The editorial corrections are good and IMO should be taken in any circumstances. I agree this change does what it says it does, so r+. One concern, which I will cross-post to the list, is that the placement of this URL in the directory means that it is not customizable; It could be a useful thing to, after a signed request, give back a URI that contains a one-time value that would help tie a browser session to a given account key. I don't see a good endpoint for such a thing at present, so the hour is probably too late for such a change.
NAME I agree that could be useful, but I can think of other, simpler ways to provide it (e.g., a link relation from a registration URI). If you think it's important, please file a follow-on issue.
NAME See my feedback on the ACME list. I disagree that this should be merged now. Could you please submit a revert and seek further discussion?
Sorry, I misunderstood. Will revert.