jiebi/CodeConvo huggingface dataset:
Change:
When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges.  The ranges MUST <del> NOT overlap.  The sender then creates N handshake messages, all with the same message_seq value as the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. Each handshake message fragment that is placed into a record MUST be delivered in a single UDP datagram. </del> <ins> NOT overlap.  The sender then creates N DTLSHandshake messages, all with the same message_seq value associated with the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.  Each handshake message fragment that is placed into a record MUST be delivered in a single UDP datagram. </ins> When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the <del> message.  DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. Senders MUST NOT change handshake message bytes upon retransmission. Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </del> <ins> message.  The transcript consists of complete TLS Handshake messages (reassembled as necessary).  Note that this requires removing the message_seq, fragment_offset, and fragment_length fields to create the Handshake structure. DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes.  Senders MUST NOT change handshake message bytes upon retransmission.  Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </ins> Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are

Discussion:
This makes the handshake the same as TLS 1.3 (modulo the version numbers, which are conveniently different.
As discussed at the meeting. NAME PTAL.
This also LGTM. Let's do a brief consensus call before merging.
Change:
2.2. <del> The request-quota is a value associated to the maximum number of </del> <ins> The service-limit is a value associated to the maximum number of </ins> requests that the server is willing to accept from one or more clients on a given basis (originating IP, authenticated user, geographical, ..) during a "time-window" as defined in time-window. <del> The "request-quota" is expressed in "quota-units" and has the </del> <ins> The "service-limit" is expressed in "quota-units" and has the </ins> following syntax: <del> The "request-quota" SHOULD match the maximum number of acceptable </del> <ins> The "service-limit" SHOULD match the maximum number of acceptable </ins> requests. <del> The "request-quota" MAY differ from the total number of acceptable </del> <ins> The "service-limit" MAY differ from the total number of acceptable </ins> requests when weight mechanisms, bursts, or other server policies are implemented. <del> If the "request-quota" does not match the maximum number of </del> <ins> If the "service-limit" does not match the maximum number of </ins> acceptable requests the relation with that SHOULD be communicated out-of-band.

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:
1.2. <del> The parties in the GNAP protocol perform actions under different roles.  Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol. </del> <ins> The parties in GNAP perform actions under different roles.  Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol. </ins> Manages the requested delegations for the RO.  The AS issues tokens and directly delegated information to the RC.  The AS is

Discussion:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.
Change:
subtype. The argument is a Singular Path and the defined type of the <del> argument is "OptionalNode" or any type of which "OptionalNode" is a subtype. </del> <ins> argument is "OptionalNodeType" or any type of which "OptionalNodeType" is a subtype. </ins> The argument is a "filter-path" or a Singular Path and the <del> defined type of the argument is "OptionalNodes". </del> <ins> defined type of the argument is "OptionalNodesType". </ins> 2.6.3.

Discussion:
This is literally just a renaming of the names in the Type column of Table 13. I also noticed that the description doesn't account for non-nodelist inputs. I'll open another issue for that.
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
Thanks!
Change:
underlying TLS using OSCORE resulting in an authenticated self- contained object. <del> 6.1. </del> <ins> 7.1. </ins> When using EST RFC7030, the following constraints should be considered:

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
direct path, "path_secret[1]" to the second parent node, and so on. Compute the sequence of HPKE key pairs "(node_priv,node_pub)", one for each node on the leaf's direct path, as follows. The node secret is derived as a temporary intermediate secret so that each secret is only used with one algorithm: The path secret is used as an input to DeriveSecret and the node secret is used as an input

Discussion:
A few changes to make code blocks a little more consistent / usable / pretty: Fence every code block with exactly three tildes Mark each code block with a type ( / / / / ) Marking with generates slightly prettier pictures for the ladder diagrams in the introduction. Marking with makes it easy to programmatically extract the TLS syntax definitions in case we want to produce a syntax summary appendix like , or in case implementers want to quickly get a listing of all the structs they need. The only substantive changes I made here were: Removing the lines from the branch and re-inject PSK illustrations Splitting pseudocode from TLS syntax in a few cases.
Yeah, I specifically had the idea because I wanted to pull out the TLS syntax blocks to update my implementation :)
Nice idea! It would also allow someone to compile the document with syntax coloration for TLS formats and Python code.
Change:
A DOH API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed <del> with HTTP mechanisms such as the Cache-Control no-cache directive </del> <ins> with HTTP mechanisms such as the "Cache-Control no-cache" directive; </ins> however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will

Discussion:
feel free to merge if my language works for you
I just now see you gave me the go ahead to merge. I'll fix the conflict and do so.
Change:
urn:ietf:params:push:receipt This link relation type is used to identify a resource for <del> creating new push message receipt subscriptions. </del> <ins> receiving delivery confirmations for push messages. (this document) The Web Push WG (webpush@ietf.org) urn:ietf:params:push:receipts This link relation type is used to identify a resource for subscribing to delivery confirmations for push messages. </ins> (this document)

Discussion:
Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.
Change:
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher <del> suite TODO:Needs to be selected [1].  (See the-cipher-suite for the </del> <ins> suite TODO:Needs to be selected [1].  (See cipher-suites for the </ins> definition.) 9.

Discussion:
This revises "The Cipher Suites" section to simplify redundant language, actually explain the de facto naming convention, and add all currently available AEAD cipher suites. It also drops the appendix table that has already had its section whittled down quite a bit, in favor of the explanation and new table in the main section. Note that this is all of the AEAD ciphers available in the current IANA registry [0], plus ChaChaPoly (which has to be a normative reference [1], so must reach RFC status before this does). Issue just said "standards track AEAD ciphers", but as the registry lists them all, adding them wasn't difficult. If we'd rather not cite them here then they can of course be cut out (ARIA, Camellia, & ECDHE AES-CCM are informational; the rest are standards track, including DHE AES-CCM). Alternatively, the table could be annotated to note which are on what track or split in two. This has no changes to any requirements. [0] URL [1] URL
NAME I addressed your comments in this new commit. I switched to a table to make things easier to read and explicitly clarified the constant string bits so as to be more clear. I also dropped the confusing sentence fragment.
looks good.
AES-OCB will also be addable to this list, but its codepoints are all completely TBD still. URL
Rebased, squashed, & updated for recent changes to draft.
Ok, all comments addressed with that last commit. I've split the table into standards and non-standards and simplified the note to just mention ECDHE AES GCM being widely deployed.
Rebased.
Ok, reworded that bit too.
I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.
NAME This was dealt with in PR and can be closed.
Change:
4.6.2. <del> Unconnected protocols such as UDP and UDP-lite generally do not </del> <ins> Connectionless protocols such as UDP and UDP-lite generally do not </ins> provide the same mechanisms that connected protocols do to offer Connection objects.  Implementations should wait for incoming packets <del> for unconnected protocols on a listening port and should perform </del> <ins> for connectionless protocols on a listening port and should perform </ins> four-tuple matching of packets to either existing Connection objects or the creation of new Connection objects.  On platforms with <del> facilities to create a "virtual connection" for unconnected protocols implementations should use these mechanisms to minimise the handling of datagrams intended for already created Connection objects. </del> <ins> facilities to create a "virtual connection" for connectionless protocols implementations should use these mechanisms to minimise the handling of datagrams intended for already created Connection objects. </ins> 4.6.3.

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
unrecognized_name alert, then this is an indication that the server is not in a default virtual host configuration. <ins> 11.3. The http-01, tls-sni-02 and dns-01 validation methods mandate the usage of a random token value to uniquely identify the challenge. The value of the token is required to contain at least 128 bits of entropy for the following security properties.  First, the ACME client should not be able to influence the ACME server's choice of token as this may allow an attacker to reuse a domain owner's previous challenge responses for a new validation request.  Secondly, the entropy requirement prevents ACME clients from implementing a "naive" validation server that automatically replies to challenges without participating in the creation of the intial authorization request. </ins> 12.  References 12.1.  URIs

Discussion:
Per feedback from Zach Shepherd[0] on the mailing list the justification for the 128 bits of required token entropy from section 8.2 is at odds with the actual rationale (as I understand it). This commit updates the justification for the entropy requirement to not mention being secret from an attacker, but instead not predictable by a naive challenge response server that would complete challenges without having been a party to the authz/chal creation.
It seems like whatever change is made should be applied to sections 8.2, 8.3, and 8.4.
Based on zjs' feedback, I think it makes more sense for the individual token fields to just say "MUST have 128 bits", and explain why in one place in the Security Considerations section.
NAME NAME Updated. Thanks for the feedback!
Change:
OuterExtensions.hash, the server aborts the connection with an "illegal_parameter" alert. <del> Clients SHOULD only use this mechanism for extensions which are large.  All other extensions SHOULD appear in both ClientHelloInner and ClientHelloOuter even if they have identical values. </del> 7. 7.1.

Discussion:
This addresses .
In Section 6.1: if I were implementing this extension, I think the simplest thing would be to compress all copied extensions by default: it's not computationally intensive; it minimizes bandwidth overhead; and it's simpler for future "big" extensions, since no code changes would be needed here. I suggest removing this guidance.
addresses this issue.
Change:
able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server. <del> Mitigated by: </del> <ins> Mitigated by: req-sec-key-protection, </ins> 4.2.17.

Discussion:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.
Change:
4.5. RFC4787 describes possible packet filtering behaviors that relate to <del> NATs.  Though the guidance there holds, a particularly unwise </del> <ins> NATs but is often also used is other scenarios where packet filtering is desired.  Though the guidance there holds, a particularly unwise </ins> behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it.  QUIC applications are encouraged to fail over to TCP if early packets do not arrive at

Discussion:
These two sections are slightly redundant, and could easily be merged because the advice they give is more or less identical.
I think better to group these two! The current filtering text describes "possible packet filtering behaviors that relate to NATs". I suggest an initial series of packet ALSO traverse other domain edge devices (such as DDOS detection, NIDS, etc) in the same way, so we should be clear that NAT/NAPT is an example:-)
discussion on 19 April editor's meeting: there's been a lot of minor editorial refactoring that improves the flow of the doc, making this merge less necessary. Still need to make sure we have examples other than NAT, though.
multiple-examples fixed in
Change:
their usage to their developers might use oblivious HTTP for some types of moderately sensitive data. <ins> These are examples of requests where there is information in a request that - if it were connected to the identity of the user - might allow a server to learn something about that user even if the identity of the user is pseudonymous.  Other examples include the submission of anonymous surveys, making search queries, or requesting location-specific content (such as retrieving tiles of a map display). </ins> 4. A client needs to acquire information about the key configuration of

Discussion:
For and NAME
I recognize that / added some conditions and use cases, but it would help readers like me to have even more. A separate explainer document/readme would be fine too. In the meeting chat today, I heard the suggestion of requesting map tiles as another use case, which makes sense to me: asking for map tiles is itself pretty revealing if connected to the user's identity (it might reveal your current location, or a location where you're going to be) and can be pretty transactional/stateless. Maybe search queries are similar. Safe browsing lookups was also mentioned. Having more example use cases might help in resolving other questions, like whether to support multiple HTTP requests at a time, or non-HTTP message bodies, etc. Ideally, we could explain the conditions under which adoption of ohttp will be useful -- maybe, a privacy need for reducing linkability of multiple requests or of a single request from user identity, and HTTP requests that are typically stateless or single-shot in some way, and frequent or performant-requiring at a certain level.
NAME added some more examples. NAME I think we can safely close this now, so I'm going to go ahead and do that. Please reopen with concrete suggestions if you think the new text is insufficient!
Change:
reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common". <del> The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) RFC8342. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
Error: Unable to parse the XML document: draft-ietf-opsawg-l3sm-l3nm-URL : Line 4822: Entity 'RFC6991' not defined : Line 4823: Entity 'RFC8294' not defined : Line 4867: Entity 'RFC8277' not defined The command "xml2rfc draft-ietf-opsawg-l3sm-l3nm-URL" exited with 1. can you update?
Change:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 11. </del> <ins> 9. </ins> <del> 11.1. </del> <ins> 9.1. </ins> The following entries are added to the "HTTP/2 Settings" registry established by RFC7540:

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.