jiebi/CodeConvo huggingface dataset:
Change:
encoded in the format specified in RFC 3339 RFC3339.  This field is REQUIRED if the "status" field is "valid". <del> The error that occurred while the server was validating the challenge, if any.  This field is structured as a problem document RFC7807. </del> <ins> Errors that occurred while the server was validating the challenge, if any, structured as problem documents RFC7807.  The server MUST NOT modify the array except by appending entries onto the end.  The server can limit the size of this object by limiting the number of times it will retry a challenge. </ins> All additional fields are specified by the challenge type.  If the server sets a challenge's "status" to "invalid", it SHOULD also

Discussion:
A refinement on Servers reflect their state in and Clients can request a retry by re-ing
Change:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The- <del> Middle attack by the fronting service.  The downside is the the client will not verify the identity of the fronting service with risks discussed in {#frontingspoofing}, but solutions will have to mitigate this risks.  Overall, end-to-end TLS to the protected service is preferable. </del> <ins> Middle attack by the fronting service.  The downside is that the client will not verify the identity of the fronting service, which enables fronting server spoofing attacks such as the "honeypot" attack discussed below.  Overall, end-to-end TLS to the protected service is preferable, but it is important to also provide a way to authenticate the fronting service. </ins> The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to

Discussion:
The delayed merge of PR left a dangling reference in the markdown source. This is an attempt to fix the issue.
Change:
A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown.  The <del> details are in the options.  A diagnostic payload MAY be included.  A peer will normally respond to a Release message by closing the TCP/ TLS connection.  Messages may be in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </del> <ins> details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </ins> Release messages are indicated by the 7.04 code (Release).

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the <del> client MUST assure uniquely identifies a given ClientInitKey object </del> <ins> client MUST ensure uniquely identifies a given ClientInitKey object </ins> among the set of ClientInitKeys created by this client. The value for init_key MUST be a public key for the asymmetric

Discussion:
I don't like the pattern of having a marker byte followed by zero-padding. It has to be parsed manually, backwards, unlike every other object in the protocol which all follow a common format.
Agreement at the interim was that people don't care about the overhead (for now), so we're going to go with the simpler, TLS-syntax-based structure.
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
Abstract <del> This document defines a YANG RPC and a minimal datastore required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in TPM-based Network Device Remote Integrity Verification.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </del> <ins> This document defines a YANG RPC and a small number of configuration node required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </ins> 1.

Discussion:
Per Jeurgen's comment that we are not building a new datastore (type)
Change:
report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server.  These connections are only used to trigger <del> retries, as described in handle-server-response.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. </del> <ins> retries, as described in rejected-ech.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. </ins> 6.1.5.

Discussion:
Handling server response discusses how to dispatch between accept/reject, but the retry flow is specifically the reject bit.
Change:
The latency spin bit enables passive latency monitoring from observation points on the network path throughout the duration of a <del> connection.  The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On- path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. </del> <ins> connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On-path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. </ins> The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in

Discussion:
while the client 'spins' it after one RTT. On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. It would be clearer to the reader if the explanation of operation proceeded the detail.
This is fine, but I find that description to be less than ideal. I won't try to suggest an improvement though. It isn't so bad.
Change:
server using QUIC or another protocol, are treated as a server with respect to this specification. <ins> For brevity, "Connection ID" will often be abbreviated as "CID". </ins> 2. 2.1.

Discussion:
Server CID will collide with Source CID.
This is often used to mean Source Connection ID in other contexts. A collision here is likely to cause confusion.
Recommended name? SCCID?
I think it might just be best to call it the "Server CID" any other abbreviated term will get confused IMO.
"Server CID" doesn't seem to fit well with "Stream Cipher Connection ID"
So SCID didn't mean "Server Connection ID"? There is definitely confusion here. I'd just recommend not abbreviating anything more than CID.
I guess this proves MT's point. "STream Cipher Connection ID" (just like PCID, OCID, BCID)
Looking again, the document never uses any acronym for 'stream cipher connection ID', so there's no issue there. This is just about 'S' meaning "source" or "server".
Change:
When a client discovers Designated Resolvers, it learns information such as the supported protocols, ports, and server name to use in certificate validation.  This information is provided in Service <del> Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. </del> <ins> Binding (SVCB) records for DNS Servers.  The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by I-D.ietf-add-svcb-dns. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net":

Discussion:
Addressing
Once it's published, we should reference the official draft for draft-schwartz-svcb-dns
Change:
<del> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </del> <ins> A DoH-only resolver at "https://doh.example/dns-query{?dns}". (DNS over TLS is not supported.): </ins> A resolver at ""resolver.example"" that supports: <del> DNS over TLS on ""resolver.example"" ports 853 (implicit in record 1) and 8530 (explicit in record 2), with ""resolver.example"" as the Authentication Domain Name, </del> <ins> DoT on ""resolver.example"" ports 853 (implicit in record 1) and 8530 (explicit in record 2), with ""resolver.example"" as the Authentication Domain Name, </ins> <del> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and </del> <ins> DoH at "https://resolver.example/dns-query{?dns}" (record 1), and </ins> an experimental protocol on "fooexp.resolver.example:5353" (record 3):

Discussion:
This wording avoids the complexity of a URI construction algorithm and is more direct and compact.
The DoH URI Template algorithm currently works like so: where $DOHPATH is "a URI Template ] encoded in UTF-8 ]." This seems not restrictive enough. For example, a valid $DOHPATH template could be "URL{?dns}," and following the algorithm above would yield "URL{?dns}," which obviously seems like not the intended result. There's text that says "The "dohpath" value MUST be chosen such that the resulting URI Template is valid for use with DNS over HTTPS," but note that the algorithm above is presented with the word MAY which, to me, implies that clients could construct the URI Template some other way. Unless there's a good reason to do so, we should be more restrictive with what $DOHPATH contains (it might be just a path component of a URI Template, or something), and how clients construct the Template.
Yes. Surely this normatively constrains the value in the way you're asking? Yes. People don't like it when you normatively require implementation of a specific algorithm, because it artificially constrains implementation. In this case, for example, a client could choose to omit the port number when it is unspecified, instead of setting it explicitly to 443. This would undeniably result in a different DoH URI Template, although the resulting calculated URIs for each request would be equivalent in some sense. A client could even skip computation of the full URI template, and instead perform substitution for each request directly on the string, plugging and and the path into their HTTP client library without ever constructing a URI.
Maybe it would be better to say that is a URI template that expands to the for each HTTP request, and remove the discussion about forming a full URL?
Change:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a </del> <ins> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a </ins> description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".

Discussion:
LGTM.
Actually, looking at a bit closer, perhaps consider: "... endpoint and cooperating intermediaries to efficiently ..." and perhaps make the Manageability reference explicitly to section 3.1 that covers identifying QUIC traffic.
Note that this is the second paragraph of the document. I'd prefer not to pile too many unrelated concepts in at this point. I think that it is OK to consider "cooperating intermediaries" to be implicit when we say "endpoint" when operating at this level of abstraction. Toward the end, where manageability is cited, is a better place for that sort of detail. I narrowed the citation to point to Section 3.1 as you suggested.
I think this update addresses NAME 's point in the telechat review.
Change:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a </del> <ins> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a </ins> description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".

Discussion:
This one says something like what Lucas said, with the caveat that the whole thing about per-connection ID is specific to spin bits, so I dropped that.
LGTM
Change:
server performs the following checks: If the ClientEncryptedSNI.key_share group does not match one in <del> the ESNIConfig.keys, it MUST abort the connection with an </del> <ins> the ESNIConfigContents.keys, it MUST abort the connection with an </ins> "illegal_parameter" alert. If the length of the "encrypted_server_name" extension is

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.
Change:
authenticating the connection for the origin server. If the value is "esni_retry_request", the client proceeds with the <del> handshake, authenticating for ESNIConfig.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. </del> <ins> handshake, authenticating for ESNIConfigContents.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 public name authenticated, the client MUST abort the connection

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.
Change:
but the list of Remote Endpoints MAY be empty if the Preconnection is used to Listen() for incoming Connections.  At least one Local Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer <del> Rendezvous is to occur based on the Preconnection. </del> <ins> Rendezvous() is to occur based on the Preconnection. </ins> If more than one Local Endpoint is specified on a Preconnection, then all the Local Endpoints on the Preconnection MUST represent the same

Discussion:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good
Change:
Packet Ordering Function. <del> Packet Switched Network. </del> Pseudowire. DetNet "service" label. <ins> Switching Provider Edge. </ins> Terminating Provider Edge. Traffic Engineering.

Discussion:
Note added to 5.1, that L4 multipath is out-of-scope. Please, check note and its placement that it is appropriate. URL URL Internet-Draft draft-ietf-detnet-ip-oam-URL is now available. It is a work item of the Deterministic Networking (DETNET) WG of the IETF. Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Authors: Greg Mirsky Mach(Guoyi) Chen David Black Name: draft-ietf-detnet-ip-oam-URL Pages: 9 Dates: 2024-02-05 Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTML version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
Hi Bernard, thank you for your thoughtful comments and helpful suggestions. The authors discussed them and updated the draft to address your concerns. I uploaded the new version: A new version of Internet-Draft draft-ietf-detnet-ip-oam-URL has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-detnet-ip-oam Revision: 11 Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Date: 2024-02-05 Group: detnet Pages: 9 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. Please let us know whether these updates adequately address your comments. Our sincere thanks for your help in improving this document. Regards, Greg (on behalf of the authors)
Change:
An example of "RateLimit-Reset" use is below. <del> The client MUST NOT assume that all its "request-quota" will be </del> <ins> The client MUST NOT assume that all its "service-limit" will be </ins> restored after the moment referenced by "RateLimit-Reset".  The server MAY arbitrarily alter the "RateLimit-Reset" value between subsequent requests eg. in case of resource saturation or to

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.