jiebi/CodeConvo huggingface dataset:
Change:
A "key-change" resource <del> For the "new-X" resources above, the server MUST have exactly one resource for each function.  This resource may be addressed by multiple URIs, but all must provide equivalent functionality. </del> <ins> For the singular resources above ("directory", "new-registration", "new-application", "revoke-certificate", and "key-change") the resource may be addressed by multiple URIs, but all must provide equivalent functionality. </ins> ACME uses different URIs for different management functions.  Each function is listed in a directory along with its corresponding URI,

Discussion:
Prior to this PR the specification seems to be contradictory, indicating that the "new-X" resources must not be duplicated, but that they can live at different URIs. It's not clear to me what this MUST is trying to prevent, especially in light of an allowance of multiple URIs if functionality is equivalent. Similarly, while the text prior to this PR says "new-X" I believe the intentions of the statements that follow would include some of the resources that have been added since, e.g. "key-change". This PR updates the "new-X" language to include the additional singular resources and removes the MUST. If I've missed the mark in this clarification perhaps someone who was involved with the spec at the time of this paragraph's writing can help guide us to something both clear & accurate to the original spirit.
Change:
In this section, we discusses those aspects of the QUIC transport protocol that have an impact on the design and operation of devices <del> that forward QUIC packets.  Here, we are concerned primarily with QUIC's unencrypted wire image WIRE-IMAGE, which we define as the information available in the packet header in each QUIC packet, and the dynamics of that information.  Since QUIC is a versioned </del> <ins> that forward QUIC packets.  Here, we are concerned primarily with the unencrypted part of QUIC's wire image WIRE-IMAGE, which we define as the information available in the packet header in each QUIC packet, and the dynamics of that information.  Since QUIC is a versioned </ins> protocol, the wire image of the header format can also change from version to version.  However, at least the mechanism by which a receiver can determine which version is used and the meaning and

Discussion:
Feel free to close this if it's out of scope, but creating a proxy that attempts to passively observe QUIC is much more complex and potentially problematic than TLS over TCP. For example, all major OS's have mature TCP implementations, whereas a MITM would have to pull in its own QUIC implementation. If it does so, it would be important that's it's both conformant to IETF specifications and have good performance. This is the full L7 termination case, which is possible, but a lot of work, and we should heavily encourage anyone doing this to use an existing("good") implementation. A potential MITM option is to attempt to terminate the handshake, but then only observe ApplicationData packets. However, this could go wrong in many ways, so I believe it should be strongly discouraged. QUIC is designed as an end-to-end protocol and efforts to change that are likely to end very poorly. For example, if the length of the CID changes, then the offset of the header changes and a middlebox who doesn't track all CIDs both peers may be unable to decrypt packets. I'm sure there are more gotchas, particularly with the introduction of extensions. It may also be worth pointing out that QUIC frames are not TLV, so any frames(ie: extensions) that are not understood cause all other frames to be unparseable. Thanks to NAME for the specific examples of ways this could fail.
Still trying to figure out what my thinking is her, but it sounds a bit like you propose something like "If you want to implement a QUIC MITM, please terminate the whole connection up to L7 and use an existing library." Note sure that is actually giving quite there right message....
As a user's guide to the wire image, one of the base assumptions we make is that access to the wire image is read only. We should definitely be more explicit about this. We also need an explicit statement that MITM is out of scope for this doc and if you want to, terminate at L7 and congrats, now everything in -transport and -tls (and, realisitically, -http) applies.
Change:
Removed support for non-AEAD ciphers <del> 1.3. This document is a revision of the TLS 1.1 RFC4346 protocol which contains improved flexibility, particularly for negotiation of cryptographic algorithms.  The major changes are: The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs.  All cipher suites in this document use P_SHA256. The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash.  Signed elements now include a field that explicitly specifies the hash algorithm used. Substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS. Addition of support for authenticated encryption with additional data modes. TLS Extensions definition and AES Cipher Suites were merged in from external TLSEXT and RFC3268. Tighter checking of EncryptedPreMasterSecret version numbers. Tightened up a number of requirements. Verify_data length now depends on the cipher suite (default is still 12). Cleaned up description of Bleichenbacher/Klima attack defenses. Alerts MUST now be sent in many cases. After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list. TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite. Added HMAC-SHA256 cipher suites. Removed IDEA and DES cipher suites.  They are now deprecated and will be documented in a separate document. Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT.  Support will probably become a SHOULD NOT in the future. Added limited "fall-through" to the presentation language to allow multiple case arms to have the same encoding. Added an Implementation Pitfalls sections The usual clarifications and editorial work. </del> 2. The goals of the TLS protocol, in order of priority, are as follows:

Discussion:
TLS 1.1 [RFC 4346] & TLS 1.2 [RFC 5246] each only have a list of changes from the immediately previous version. This current draft has both the current changelog since TLS 1.2 and the old list of changes from TLS 1.1 to 1.2. The contents of this old section are no longer relevant, in particular it mentions TLSRSAWITHAES128CBCSHA as MTI which is no longer permitted at all. Suggesting just removing this now.
Thanks. Merged.
Change:
3. Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest <del> message. </del> <ins> messages. </ins> 4. <del> Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange message. If client does receive a MD5 or SHA-1 signature in the ServerKeyExchange message and it sent one in signature_algorithms extensions it MUST abort the connection with handshake_failure or insufficient_security alert.  If client did not send MD5 nor SHA-1 hash algorithm in signature_algorithms extension and it receives a MD5 or SHA-1 signature in the ServerKeyExchange it MUST abort the connection with the illegal_parameter alert. </del> <ins> Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </ins> 5. <del> Clients MUST NOT include MD5 and SHA-1 in CertificateVerify message. If the server receives a CertificateVerify message with MD5 or SHA-1 it MUST abort the connection with handshake_failure or </del> <ins> Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it MUST abort the connection with handshake_failure or </ins> insufficient_security alert. 6.

Discussion:
As per discussion on mailing list.
NAME can you please float this change on the mailing list?
Change:
2.4.1. <del> Every JSONPath query MUST begin with the root identifier "$". </del> <ins> Every JSONPath query (except those inside filter expressions, see filter-selector) MUST begin with the root identifier "$". </ins> 2.4.2.

Discussion:
Fixes URL
Section 1.4 says: >A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more selectors. So this includes relative paths (starting with ). However, section 1.4.1 contradicts this: Similarly, section 2.4 says: >Every JSONPath query MUST begin with the root identifier . (Remember that, according to our terminology, "query" is a short name for a JSONPath expression.) A possible solution is for sections 1.4.1 and 2.4 to talk about JSONPath expressions/queries which do not appear inside a filter expression.
Change:
ACME Identifier Types (iana-identifier) <del> ACME Challenge Types (iana-challenge) </del> <ins> ACME Validation Methods (iana-validation) </ins> All of these registries are under a heading of "Automated Certificate Management Environment (ACME) Protocol" and are administered under a

Discussion:
It is useful in some contexts (e.g., ) to have identifiers for non-ACME methods that CAs use to validate control of an identifier. This PR updates the ACME Challenge Types registry to instead address Validation Methods more generally, with a column that indicates whether the method is an ACME method.
Okay, I see your point. Fine.
Change:
The time between the creation of Claims and the collection of Claims is indistinguishable. <ins> 10.3. A third approach relies on having epoch "handles" periodically sent to both the sender and receiver of Evidence or Attestation Results by some "Handle Distributor". Handles are different from nonces as they can be used more than once and can even be used by more than one entity at the same time. Handles are different from timestamps as they do not have to convey information about a point in time, i.e., they are not necessarily monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle in received Evidence or Attestation Results against the latest handle it received from the Handle Distributor to determine if it is within the current epoch.  An actual solution also needs to take into account race conditions when transitioning to a new epoch, such as by using a counter signed by the Handle Distributor as the handle, or by including both the current and previous handles in messages and/or checks, by requiring retries in case of mismatching handles, or by buffering incoming messages that might be associated with a handle that the receiver has not yet obtained. Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or Verifiers from which it expects to receive Evidence or Attestation Results, as long as all use the same Handle Distributor. 10.4. </ins> Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved <del> peers, followed by any number of timestamp based exchanges.  In another setup where all Roles (Attesters, Verifiers and Relying Parties) share the same broadcast channel, the nonce-based approach may be used to anchor all parties to the same (relative) timeline, without requiring synchronized clocks, by having a central entity emit nonces at regular intervals and have the "current" nonce included in the produced Evidence or Attestation Result. </del> <ins> peers, followed by any number of timestamp based exchanges. </ins> It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the

Discussion:
Per last week's design team discussion. Signed-off-by: Dave Thaler
In general, I like the re-introduction of the "timekeeping" subsections a lot. +1
Change:
character class containing the single character "^". This is essentially XSD regexp without character class subtraction <del> and multi-character escapes. </del> <ins> and multi-character escapes such as "s", "S", and "w". </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the

Discussion:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by
Change:
response, which might not be what some clients want. A proxy can use padding to reduce the effectiveness of traffic <del> analysis. </del> <ins> analysis.  Padding is a capability provided by binary HTTP messages; see Section 3.8 of BINARY. </ins> A proxy that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.

Discussion:
See discussion on-list.
See also URL
If we're pinning the contents of the encapsulation to message/bhttp, it seems like we also ought to change the HPKE info strings to match ("request" -> "message/bhttp-request" or whatever). When someone tries to reuse this layer of encapsulation, I think they ought to change the info string accordingly to match whatever the underlying type is. And it might not hurt to add guidance to such people in the security considerations. Can we do this in a followup PR?
I agree that we should think about content types a bit more, but that seems appropriate for another PR.
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The format I've sketched out for binary messages can be padded with zeros without needing a separate padding field. That's probably a feature worth mentioning in both drafts.
Padding is in the binary HTTP draft now.
Change:
Thus, trusting a Verifier might be expressed by having the Relying Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate <del> of an entity (e.g., a Certificate Authority) that is in the </del> <ins> of an entity (e.g., a Certification Authority) that is in the </ins> Verifier's certificate path.  For example, the Relying Party can verify that the Verifier is an expected one by out-of-band establishment of key material, combined with a protocol like TLS to

Discussion:
You want to say "Certification Authority" not "Certificate Authority"
yeah. thanks for catching that!
Change:
The scheme, "https:".  An IdP MUST be loaded using RFC2818. <del> The authority, which is the IdP domain name.  The authority MAY contain a non-default port number.  Any port number is removed </del> <ins> The RFC3986.  As noted above, the authority MAY contain a non- default port number or userinfo sub-component.  Both are removed </ins> when determining if an asserted identity matches the name of the <del> IdP.  The authority MUST NOT include a userinfo sub-component. </del> <ins> IdP. </ins> The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol.  Note that the separator characters '/'

Discussion:
This references RFC 3986 authority instead of providing a definition for IdP domain. This change means that userinfo sub-components are permitted, as are non-default ports, but also states that both are removed before matching against the certificate.
Change:
the cryptographic algorithms listed continue to provide the expected level of security. <ins> Designated experts ensure the specification is publicly available. They may provide more in depth reviews.  Their review should not be taken as an endorsement of the cipher suite, extension, supported group, etc. </ins> 19. This document is entirely about changes to TLS-related IANA

Discussion:
Addresses and .
Seems like we should add a security consideration about the expert and how much review they're going to do.
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.
Change:
make it a full-service resolver), but some recursive resolvers might not cache. <ins> A query with the Recursion Desired (RD) bit set to 1 in the header.(See Section 4.1.1 of RFC1035.)  If recursive service is available and is requested by the RD bit in the query, the server uses its resolver to answer the query.  (See Section 4.3.2 of RFC1035.) A query with the Recursion Desired (RD) bit set to 0 in the header.  A server can answer non-recursive queries using only local information: the response contains either an error, the answer, or a referral to some other server "closer" to the answer. (See Section 4.3.1 of RFC1035.) Synonym for non-recursive query that happens to be a query in a series of recursive queries, but that is itself not a recursive query.  This term is used in a number of RFCs though never explicitly defined. A name server may be presented with a query that can only be answered by some other server.  The two general approaches to dealing with this problem are "recursive", in which the first server pursues the query for the client at another server, and "iterative", in which the server refers the client to another server and lets the client pursue the query there.  (See Section 2.3 of RFC1034.) In iterative resolution, the client repeatedly makes non-recursive queries and follows referrals and/or aliases.  The iterative resolution algorithm is described in Section 5.3.3 of RFC1034. </ins> "The act of finding the list of root servers from a configuration that lists some or all of the purported IP addresses of some or all of those root servers."  (Quoted from RFC8109, Section 2.)

Discussion:
…erative resolution
Agree with your fix to the definition.
During the lead-up to RFC 7719, Tony Finch asked for four terms to be defined: Recursive query Non-recursive query Iterative query Iterative resolution The were not in RFC 7719 but could be in the -bis.
Updated the document in URL
I don't think iterative query is a synonym. I think an iterative query is a non-recursive query that happens to be a query in a series of recursive queries but that is itself not a recursive query. No? That seems more consistent with the iterative resolution definition that follows.
Change:
no token. The service SHOULD decrypt incoming tokens.  The service SHOULD drop <del> packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </del> <ins> packets with unknown key sequence, or an AEAD ICV that does not match the expected value.  (By construction, the AEAD ICV will only match if the client IP Address also matches.) </ins> <del> If the token checksum passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. </del> <ins> If the token verification passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. </ins> Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below.

Discussion:
detail info: fix a typo. change AEAD checksum to AEAD ICV(defined in rfc4106)
Hi martin: is not a standard name of AEAD verification message, which should be , see section 6 of rfc4106
Change:
This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on <del> network operations involving QUIC traffic.  Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. </del> <ins> network operations involving QUIC traffic.  It is intended as a "user's manual" for the wire image, providing guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. </ins> 1.

Discussion:
As this document does not use normative language and still makes number of recommendations, I think it is best that the abstract and/or introduction of thid document need some text to clarify how the readers should interpret those recommendations URL
What exactly would you propose?
hmm, the reason for not using normative language would be sufficient I think.
Not sure what to write. There is no requirement that normative language must be used in RFC and moreover this is not a protocol specification. However, these are not something that we should note in the abstract.
Can you make a proposal?
I would simply expect the reason of not using normative language in this document (I remember there was some discussions on it), perhaps best fit in the introduction section.
There is nothing really specific here. If you look at the other issue they don't say much other than that we only provide recommendation and therefore don't need normative language. I would prefer to not say anything as that could rather give a wrong impression.