jiebi/CodeConvo huggingface dataset:
Change:
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, <del> Lucas Pardue, Mark Nottingham, Matt Stock, Michael Scharf, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del> <ins> Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, Tommy Pauly, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References

Discussion:
Also adding Tommy's name in Acks section.
LGTM, too and ready to merge.
From NAME In Section 6.1 (on UDP), DNS queries are described as follows: "DNS, which is often used to send a single-packet request to look up the IP address for a DNS name, and return a single-packet response containing the IP address." I'm not sure how valuable this example is for explaining UDP, but if it is kept, please say that multiple packets are sent to get multiple addresses. With IPv6 and IPv4, clients query for both A and AAAA records, and handle multiple addresses, especially for IPv6.
FWIW, I understand why you're saying this. My point (and I wrote this) was to explain why it we've used DNS over UDP for decades without worrying about congestive collapse, but we've used other protocols over TCP because we were worried. I can certainly explain that more correctly, as you propose. And thanks for pushing back.
Hi, NAME especially after NAME suggesting in his TSVART review that I don't need to talk about history, removing this text completely was a perfectly reasonable resolution for your issue!
Sounds good
LGTM
Change:
A.  If the request was an Observe registration, then: <del> If the Partial IV is not present in the response, and either the client has previously received a successful notification to the registration (active observation) or Inner Observe is present, then go to 8. </del> <ins> If the Partial IV is not present in the response, and Inner Observe is present, and the nonce from the request was already used once, then go to 8. </ins> If the Partial IV is present in the response and Inner Observe is present, then follow the processing described in notifications and

Discussion:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
6. If, given an authenticator request, the endpoint does not have an <del> appropriate certificate or does not want to return one, it constructs an authenticated refusal called an empty authenticator.  This is a </del> <ins> appropriate identity or does not want to return one, it constructs an authenticated refusal called an empty authenticator.  This is a </ins> Finished message sent without a Certificate or CertificateVerify. This message is an HMAC over the hashed authenticator transcript with a Certificate message containing no CertificateEntries and the

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
Endpoint or a Remote Endpoint in cases where this is required, for example with some NAT traversal protocols (see rendezvous). <del> [NOTE: the API needs MUST be explicit about when name resolution occurs, since the act of resolving a name leaks information, and there may be security implications if this happens unexpectedly.] </del> 5.2. A Preconnection object holds parameters reflecting the application's

Discussion:
There are still a few s and similar scattered throughout the document. Find them and fix them, or move them to post-London issues.
Change:
bandwidth. An implementation should use this information, when possible, to <del> determine preference between candidate paths, endpoints, and protocol </del> <ins> influence preference between candidate paths, endpoints, and protocol </ins> options.  Eligible options that historically had significantly better performance than others should be selected first when gathering candidates (see gathering) to ensure better performance for the

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
Specific Properties can significantly reduce the flexibility of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that Protocol <del> Properties are normnally used for properties common across different protocols and that Protocol Specific Properties are only used where specific protocols or properties are necessary. </del> <ins> Properties are used for properties common across different protocols and that Protocol Specific Properties are only used where specific protocols or properties are necessary. </ins> The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can

Discussion:
Be firm, but avoid MUST NOT apply across different protocols TO ADDRESS
This was discussed at the Interim and final text approved by MW.
In section 8's third paragraph, the MUST NOT is not a good use of 2119/8174. Are you trying to say protocol specific property names must not be reused across different protocols?
I note that the current text was: "Protocol Specific Properties are defined in a transport- and implementation-specific way, and MUST NOT apply across different protocols. Too much reliance by an application on Protocol Specific Properties can significantly reduce the flexibility of a transport services implementation."
Decision: avoid this language, say "architecture expects that ... "
Say this is important but only recommend.
Change:
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this draft is maintained in GitHub.  Suggested changes should be submitted <del> as pull requests at https://github.com/ekr/mls-protocol. </del> <ins> as pull requests at https://github.com/mlswg/mls-protocol. </ins> Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the MLS mailing list.

Discussion:
Note: If you have an existing clone, you will need to delete at the root level of the clone in order for to work. ( will still work fine)
Change:
5.4. <del> When performing a Commit, the generator of the Commit updates its leaf KeyPackage and its direct path to the root with new secret values.  The HPKE leaf public key within the KeyPackage MUST be derived from a freshly generated HPKE secret key to provide post- compromise security. The generator of the Commit starts by sampling a fresh random value called "leaf_secret", and uses the leaf_secret to generate their leaf HPKE key pair (see key-packages) and to seed a sequence of "path secrets", one for each ancestor of its leaf.  In this setting, </del> <ins> A member of an MLS group advances the key schedule to provide forward secrecy and post-compromise security by providing the group with fresh key material to be added into the group's shared secret.  To do so, one member of the group generates fresh key material, applies it to their local tree state, and then sends this key material to other members in the group via an UpdatePath message (see update-paths) . All other group members then apply the key material in the UpdatePath to their own local tree state to derive the group's now-updated shared secret. To begin, the generator of the UpdatePath updates its leaf KeyPackage and its direct path to the root with new secret values.  The HPKE leaf public key within the KeyPackage MUST be derived from a freshly generated HPKE secret key to provide post-compromise security. The generator of the UpdatePath starts by sampling a fresh random value called "leaf_secret", and uses the leaf_secret to generate their leaf HPKE key pair (see key-packages) and to seed a sequence of "path secrets", one for each ancestor of its leaf.  In this setting, </ins> path_secret[0] refers to the node directly above the leaf, path_secret[1] for its parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding

Discussion:
This PR updates two sections to reference generating and sending an message, as not all Commits transmit fresh key material (as discussed in ). This PR also includes light editorial edits for clarity and adds detail around the steps to perform an update. Section 7.7 currently says that "each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path", but section 10.2 says that an UpdatePath is optional. I can update 7.7 as well, if 10.2 is correct.
I went ahead and changed Section 7.7 to specify that MLS commits may optionally transmit updates for consistency with Section 10.2
Change:
An authenticator message can be constructed by either the client or the server given an established TLS connection, an identity, such as <del> an X509 certificate, and a corresponding private key.  Clients MUST </del> <ins> an X.509 certificate, and a corresponding private key.  Clients MUST </ins> NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional.  For authenticators that do not correspond to authenticator requests, the

Discussion:
got merged while I was reviewing it, so here's my feedback as a follow-up PR. I initially though line 244 needed a comma, but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity, so I dropped that one.
Thanks, Mike.
Change:
The identifier itself. <del> How an existing authorization should be handled.  Possible values are "accept" and "require". </del> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the identifier.  For example, the server should check that the identifier

Discussion:
I believe they are unnecessary. The server can set its own policy on whether to give back an existing or a new authz, and the client can choose to accept or reject that. Hugo also pointed out on-list that the status codes for these are inconsistent with the status codes for new-account. If we keep these, we'd want to fix that. But simpler to delete, I think.
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
2.4. <del> An example of missing glue is included here, even though it is not really a type of glue.  While not common, real examples of responses that lack required glue, and with TC=0, have been shown to occur and cause resolution failures. </del> <ins> An example of missing glue is included here, even though it can not be considered as a type of glue.  While not common, real examples of responses that lack required glue, and with TC=0, have been shown to occur and cause resolution failures. </ins> The example below is based on a response observed in June 2020.  The names have been altered to fall under documentation domains.  It

Discussion:
and talk more generically about message size constraints regardless of transport. For
As currently written the document only talks about setting TC=1 over UDP. This sort of implies that UDP is the only possible transport where TC flag has meaning. We don't talk about setting TC over TCP because the assumption is that TCP always has enough room for all glue or whatever. But this doesn't account for two possibilities 1) a future transport that is limited in space 2) some kind of ridiculous zone configuration with so many NS and glue records that they won't even fit in a single DNS-over-TCP message. Would it be better to just say "set TC=1 if glue doesn't fit" and not bring UDP or TCP into the requirements language?
I like the idea of that, but I think simultaneous possession and ingestion of cake is also possible -- make the general, transport-agnostic point but also give the UDP/TCP fallback as an example that is known to be common at the time of writing. Joe
I prefer mentioning UDP and TCP and to say clearly never set it for TCP. I wouldn't consider "insanely weird" TCP that requires TC=1
would or wouldn't?
was merged so closing this for now
Change:
7.6.2. A sender establishes persistent congestion after the receipt of an <del> acknowledgement if at least two ack-eliciting packets are declared </del> <ins> acknowledgement if two packets that are ack-eliciting are declared </ins> lost, and: all packets, across all packet number spaces, sent between the <del> send times of two ack-eliciting packets are declared lost; </del> <ins> send times of these two packets are declared lost; </ins> the duration between the send times of these two packets exceeds the persistent congestion duration (pc-duration); and <del> a prior RTT sample existed when both packets were sent. </del> <ins> a prior RTT sample existed when these two packets were sent. </ins> These two packets MUST be ack-eliciting, since a receiver is required to acknowledge only ack-eliciting packets within its maximum ack

Discussion:
NAME rightly noted lack of clarity (), which this PR attempts to fix. There's a new MUST here, but I think it was again implicit. EDIT: Removed this MUST since NAME notes correctly that this is a definition, not an action.
Change:
ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref] <del> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </del> 6. It is possible to change elements in the SDP returned from

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
indicate which signature algorithms it can validate in X.509 certificates. <ins> The term "master" as applied to secrets has been removed, and the "extended_master_secret" extension RFC7627 has been renamed to "extended_main_secret". </ins> Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see protocol-invariants.

Discussion:
I wasn't sure where to put this text. There was an Appendix talking about TLS 1.2, so I figured it could go nearby. And then it probably wanted to go before that Appendix so there isn't ambiguity about how to refer to EMS.
Implementations of TLS 1.2 will remain for some time. The document renames "master secret" to "main secret", but TLS 1.2 has some naming variations that aren't in TLS 1.3. Perhaps a section in the document somewhere (maybe under Backward Compatibility since that talks about older versions) that describes some additional deltas: "master secret" => "main secret", to align this this document "premaster secret" => "preliminary secret" ("pre-main secret" sounds weird to me) "extended master secret" => "extended main secret" (probably move rfc7627 from informative to normative and then also add to the updates line) Also cover the variations like "EncryptedPreMasterSecret" and "mastersecret", but not the KDF labels since those can't change. And then IANA considerations to rename extendedmastersecret to extendedmain_secret in the registries.
Change:
Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern <del> (syntax-index).  No attempt was made to improve on this syntax, so characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("&#129300;", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </del> <ins> (syntax-index).  No attempt was made to improve on this syntax, so if it is desired to escape characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("&#129300;", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), they need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </ins> 2.5.1.2. <del> A "name-selector" string MUST be converted to a member name M by </del> <ins> A "name-selector" string MUST be converted to a member name "M" by </ins> removing the surrounding quotes and replacing each escape sequence with its equivalent Unicode character, as in the table below: Applying the "name-selector" to an object node selects a member value <del> whose name equals the member name M, or selects nothing if there is </del> <ins> whose name equals the member name "M", or selects nothing if there is </ins> no such member value.  Nothing is selected from a value that is not an object. Note that processing the name selector requires comparing the member <del> name string M with member name strings in the JSON to which the </del> <ins> name string "M" with member name strings in the JSON to which the </ins> selector is being applied.  Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to <del> either the member name string M from the JSONPath or to the member </del> <ins> either the member name string "M" from the JSONPath or to the member </ins> name strings in the JSON prior to comparison. 2.5.1.3.

Discussion:
Wouldn't mind if we could get these editorials merged quickly so the bulk of the other PRs shrinks a bit.
LGTM, thanks.
Change:
an identifier proactively, outside of the context of a specific issuance.  For example, a client hosting virtual servers for a collection of names might wish to obtain authorization before any <del> servers are created, and only create a certificate when a server starts up. </del> <ins> virtual servers are created, and only create a certificate when a virtual server starts up. </ins> In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.