jiebi/CodeConvo huggingface dataset:
Change:
Abstract <del> RFC 5280 specifies several extended key usages for X.509 certificates.  This document defines a general purpose document signing extended key usage for X.509 public key certificates which restricts the usage of the certificates for document signing. </del> <ins> RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  This document defines a general purpose document signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. Document Signing applications may require that the EKU extension be present and that a document signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document Signing application. </ins> 1. <del> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been added RFC7299 as public Object Identifier (OID) under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined OID for general document signing purposes. </del> <ins> RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  In addition, several KeyPurposeIds have been addedRFC7299 under the IANA repository "SMI Security for PKIX Extended Key Purpose".  While usage of the "anyExtendedKeyUsage" KeyPurposeId is bad practice for publicly trusted certificates, there is no public and general KeyPurposeId explicitly assigned for Document Signing.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or a vendor-defined KeyPurposeId for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes

Discussion:
Try to used KeyPurposeId (or key purpose, key purpose identifier, etc.), to express more accurately. Add some changes, related with restrictive expression of document signing KeyPurposeId, etc.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.
Change:
X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where <del> the properties differ from the leaf certificate.  For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. </del> <ins> the properties differ from the leaf certificate.  Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide are not necessary.  For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. </ins> Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end-

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:
find out the plaintext by correlation between the question and the length. <del> Similarly to TLS 1.3, if padding is used, the MLS messages MUST be padded with zero-valued bytes before AEAD encryption.  Upon AEAD decryption, the length field of the plaintext is used to compute the number of bytes to be removed from the plaintext to get the correct data.  As the padding mechanism is used to improve protection against traffic analysis, removal of the padding SHOULD be implemented in a "constant-time" manner at the MLS layer and above layers to prevent timing side-channels that would provide attackers with information on the size of the plaintext.  The padding length length_of_padding can be chosen at the time of the message encryption by the sender. Recipients can calculate the padding size from knowing the total size of the ApplicationPlaintext and the length of the content. </del> <ins> The content and length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  It is recommended that padding data is comprised of zero-valued bytes and follows an established deterministic padding scheme. </ins> 14.2.

Discussion:
The padding section was out of date based on prior changes.
In section 14.1 Message Encryption and Decryption there is a paragraph describing the reasons why you would want to use padding, and part of that mentions the following As the padding mechanism is used to improve protection against traffic analysis, removal of the padding SHOULD be implemented in a "constant-time" manner at the MLS layer and above layers to prevent timing side-channels that would provide attackers with information on the size of the plaintext. The padding length lengthofpadding can be chosen at the time of the message encryption by the sender. This seems out of date given that padding is a separate field that doesn't need to be explicitly stripped off at decrypt time and there is no other mention of in the document.
That seems right. We used to have a more clever, more economical padding scheme mirroring what TLS does. But that got rationalized a while ago. These are probably dangling references. Want to send a PR?
Sounds good, pushed PR URL
Change:
directly to that provider, which has access to the plaintext of the connection. <del> In Split Mode, the provider is _not_ the origin server for hidden domains.  Rather the DNS records for hidden domains point to the </del> <ins> In Split Mode, the provider is _not_ the origin server for private domains.  Rather the DNS records for private domains point to the </ins> provider, but the provider's server just relays the connection back <del> to the hidden server, which is the true origin server.  The provider </del> <ins> to the backend server, which is the true origin server.  The provider </ins> does not have access to the plaintext of the connection.  In principle, the provider might not be the origin for any domains, but as a practical matter, it is probably the origin for a large set of <del> innocuous domains, but is also providing protection for some hidden domains.  Note that the hidden server can be an unmodified TLS 1.3 </del> <ins> innocuous domains, but is also providing protection for some private domains.  Note that the backend server can be an unmodified TLS 1.3 </ins> server. 3.2.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
3.6. Home and commercial building automation systems can benefit from the <del> use of M2M web services.  The discovery requirements of these </del> <ins> use of IoT web services.  The discovery requirements of these </ins> applications are demanding.  Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time

Discussion:
Use case HA/BA: Expand and reference term "6LBR" Use case HA/BA: Use term 'IoT' that's more common in that area these days
Change:
server. The server encrypts the server ID using exactly the algorithm as <del> described in triple-stream-cipher-load-balancer-actions, performing the three passes in reverse order. </del> <ins> described in stream-cipher-load-balancer-actions, performing the three passes in reverse order. </ins> <del> 4.5. </del> <ins> 4.4. </ins> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
An endpoint that supports receiving the "WTHEADERS" as part of the WebTransport protocol SHOULD send this setting with a value of 1. <del> 3.4. </del> <ins> 3.6. </ins> An endpoint that wishes to establish a WebTransport session over an HTTP/2 stream follows the extended CONNECT handshake procedure

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an <del> "unsupported_certificate" alert. </del> <ins> "unsupported_certificate" alert.  Any given OID MUST NOT appear more than once in the filters list. </ins> PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching

Discussion:
We should say something about whether the same OID is allowed to appear multiple times in the oid_filters extension (and if it is, what the semantics are). Extracted from
As noted in my comments, there is a natural semantic for multiple, but it seems a bit silly. I think it would be fine to forbid them, though.
I think it's OK to limit to one appearance of a given OID in the oid_filters. (It probably does not matter much in terms of code complexity either way.)
I'm inclined to limit to one appearance of a given OID in oid_filters.
I guess it's implicit that there is no meaning to the order in which oid/values appear, and we don't need to say anything about that.
Change:
2.7. <del> Segments apply one or more selectors to an input value and concatenate the results into a single nodelist. </del> <ins> For each node in an input nodelist, segments apply one or more selectors to the node and concatenate the results of each selector into per-input-node nodelists, which are then concatenated in the order of the input nodelist to form a single segment result nodelist. </ins> It turns out that the more segments there are in a query, the greater the depth in the input value of the nodes of the resultant nodelist:

Discussion:
Add clarifications that the input nodelist provides the outer order, the segments provide a middle-level order, and selectors (if multiple) provide the inner order. This may have been obvious to some readers, but now should be obvious to more, including yours truly.
I don't think the example for in Table 17 is right. URL It says: It should be: Note that the descendants list puts out before and . The wildcard selector then has no choice but outputting , , , .
Nice catch! The example needs fixing as does the ordering note below Table 17.
I let the computer do the catching :-) Do you want to make these changes? I'd do a new issue then. (And wait a bit for Greg to catch up.)
NAME Yes, I'm happy to do that and please do create a new issue. I won't be able to fix it before the weekend at the earliest though.
URL
LGTM thanks. Semantics unchanged, but hopefully a lot clearer.
Change:
If the value is "esni_accept", the client MUST check that the extension's "nonce" field matches ClientESNIInner.nonce and otherwise abort the connection with an "illegal_parameter" alert. <del> The client then proceeds with the connection as usual, verifying the certificate against the desired name. </del> <ins> The client then proceeds with the connection as usual, authenticating the connection for the origin server. </ins> If the value is "esni_retry_request", the client proceeds with the <del> handshake, verifying the certificate against ESNIKeys.public_name as described in verify-public-name.  If verification or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT use the retry keys. </del> <ins> handshake, authenticating for ESNIKeys.public_name as described in auth-public-name.  If authentication or the handshake fails, the client MUST return a failure to the calling application.  It MUST NOT use the retry keys. </ins> Otherwise, when the handshake completes successfully with the <del> public name verified, the client MUST abort the connection with an "esni_required" alert.  It then processes the "retry_keys" field from the server's "encrypted_server_name" extension. </del> <ins> public name authenticated, the client MUST abort the connection with an "esni_required" alert.  It then processes the "retry_keys" field from the server's "encrypted_server_name" extension. </ins> If one of the values contains a version supported by the client, it can regard the ESNI keys as securely replaced by the server.

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
order of client preference.  If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as <del> usual.  Values are defined in cipher-suites. </del> <ins> usual.  Values are defined in cipher-suites.  If the client is attempting a PSK key establishment, it SHOULD advertise at least one cipher suite containing a Hash associated with the PSK. </ins> Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field.  For every

Discussion:
This is how NSS behaves as well. This seems like a reasonable argument.
added the changes previously discussed.
I did not verify that the moved text is only move and no edits, but the other chunks seem okay.
NAME are you OK with this SHOULD?
Sounds reasonable. Mostly I just don't want to encourage servers to enforce anything about this.
Change:
timezone to the timestamp in a non-standard format, at least one of which is fairly well-adopted JAVAZDT.  Furthermore, applications might want to attach even more information to the timestamp, <del> including but not limited to the calendar system it must be </del> <ins> including but not limited to the calendar system it needs to be </ins> represented in. This document defines an extension syntax for timestamps as specified

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an <del> (incorrect) older profile string. </del> <ins> (incorrect) older profile string.  This simplifies JSEP behavior, with minimal downside, as any remote endpoint that fails to handle such a re-offer will also fail to handle a JSEP endpoint's initial offer. </ins> 5.2.

Discussion:
The last paragraph of 5.1 needs more context. Why woudn't you expect the re-offer to fail, given that you already know the peer is using the older profile strings? It's not clear from the email list and proceedings how the document ended up with this particular text.
Consensus on editor's call is that this is correct. Rationale is that a new offer would have failed in any case, so why complicate things.
LGTM
Change:
registration resource.  The registration resource location thus returned is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered <del> links, including updating and deleting links. </del> <ins> links, including updating and deleting links.  A registration with an already registered ep and d value pair responds with the same success code and Location as the original registration; the set of links registered with the endpoint is replaced with the links from the payload. </ins> 4.00 "Bad Request" or 400 "Bad Request".  Malformed request. <del> 4.09 "Conflict" or 409 "Conflict".  Attempt to create a registration resource with ep and d value pair which is already present in an earlier created registration resource. </del> 5.03 "Service Unavailable" or 503 "Service Unavailable".  Service could not perform the operation.

Discussion:
The description of the Registration interface describes it as idempotent, I think it should be idempotent on CoAP and not only on application level -- the same request results in the same response with no further state change. As to what happens when the re-registration arrives with a different set of links, there we have options; I went for "replaces the registration" here, but a 4.09 in that case would be just as valid an option. NAME that topic came up with the removal of the plurality removal at URL Do you agree with the basic proposition of "an unmodified request should be 2.04", and do you think replacing is the right way, or 4.09 if the links don't match?
Replacement is OK, given the removal of "addition of inks" with a POST. Conflicts are indeed impossible then.
Change:
3.2. The "RateLimit-Remaining" response field indicates the remaining <del> "quota-units" defined in request-quota associated to the client. </del> <ins> "quota-units" defined in service-limit associated to the client. </ins> The field value is

Discussion:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.
Change:
9.3. This document will request IANA to create an "HTTP Datagram Flow <del> Identifier Parameters" registry.  Registrations in this registry MUST include the following fields: </del> <ins> Parameters" registry.  Registrations in this registry MUST include the following fields: </ins> The key of a parameter that is associated with a datagram flow <del> identifier list member (see header).  Keys MUST be valid structured field parameter keys (see Section 3.1.2 of STRUCT- FIELD). </del> <ins> list member (see header).  Keys MUST be valid structured field parameter keys (see Section 3.1.2 of STRUCT-FIELD). </ins> A brief description of the parameter semantics, which MAY be a summary if a specification reference is provided.

Discussion:
This somewhat of an experiment. While trying to address I got distracted by the document's use of the "flow identifier" term. The document likes to compare "flow identifiers" with QUIC streams, which is fine. But QUIC makes the distinction between streams and stream IDs; the ID is a property of the stream but it isn't the only one, and sometimes it helps to talk about the stream in other contexts. This change tries to channel a similar editorial style. It replaces: "flow identifiers" with "flows" when talking about a logical entitiy "flow identifiers" with "flow IDs" when talking about the wire format, encoding, examples etc. This could be a change too far but I figured it would be a good discussion starter.
The draft doesn't do this. It relies on the QUIC varint encoding for non-negativity in DATAGRAM frames but could contain a negative value. Let's be clear in the spec.
Definitely agree, could you write a PR please?
I will.
fixed in URL
Thanks!