jiebi/CodeConvo huggingface dataset:
Change:
6. <del> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). 7. </del> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester.  Such trust might come by the Relying

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
The creation of a registry MAY identify a range of codepoints where registrations are governed by a different registration policy.  For <del> instance, the registries for 62-bit codepoints in this document have stricter policies for codepoints in the range from 0 to 63. </del> <ins> instance, the frame type registry in iana-frames has a stricter policy for codepoints in the range from 0 to 63. </ins> Any stricter requirements for permanent registrations do not prevent provisional registrations for affected codepoints.  For instance, a <del> provisional registration for a frame type (iana-frames) of 61 could be requested. </del> <ins> provisional registration for a frame type of 61 could be requested. </ins> All registrations made by Standards Track publications MUST be permanent.

Discussion:
NAME You have a comment here pending. I'm planning to merge this PR in ~15 hours from now, so please say something now if you still would prefer a change.
Section 22.1.4: "For instance, the registries for 62-bit codepoints in this document have stricter policies for codepoints in the range from 0 to 63." Looking then at 22.2 it states: The "QUIC Transport Parameters" registry governs a 62-bit space. This registry follows the registration policy from Section 22.1. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]). No mention of the special registration rule for values in the 0-63 range. Section 22.3 and 22.4 do have these special rules. So should 22.1.4 be changed to state "may"/"sometime" have this rule. Or should a special rule be added to 22.2 and the version registry?
Change:
in the same way as the path MTU, but it is a property of the endpoint and not the path.  It is expected that this is the space an endpoint dedicates to holding incoming packets. <del> initial_max_data (0x04): </del> The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
push service.  This could force the user agent to serialize subscription requests to the push service. <del> A user agent that monitors subscriptions for other clients might require multiple subscription sets.  Each subscription set can then be managed independently, which might include being moved between user agents. </del> 8. This protocol MUST use RFC2818.  This includes any communications

Discussion:
I ensured that the "proxy" text in UA and AS were similar. I removed the cross-references to and added text in Section 7.5, which is specific to PS policies if it doesn't want to support multiple subscription sets. I did not call out potential UA scenarios in detail other than "monitoring on behalf" of other receivers or senders. WebPush provides a mechanism to enable proxies - but it may be better to have separate drafts that describe specific policies that use this mechanism to support scenarios such as moving between UA(s).
NAME and NAME - please review and comment.
LGTM, but I'll wait until others have commented before merging.
This works for me.
Change:
control unless it has an out-of-band way of knowing with absolute certainty that the inner traffic is congestion-controlled. <ins> If a client or proxy with a connection containing a CONNECT-UDP stream disables congestion control, it MUST NOT signal ECN support on that connection.  That is, it MUST mark all IP headers with the Not- ECT codepoint.  It MAY continue to report ECN feedback via ACK_ECN frames, as the peer may not have disabled congestion control. </ins> When the protocol running over UDP that is being proxied uses loss recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery

Discussion:
On a related note, the text in #performance talks about disabling congestion control on a "connection," but I believe this is actually a per-endpoint decision. (The client could easily have more information than the proxy on the tunneled connections).
Even if CONNECT-UDP has no explicit ECN support without an extension, there is ambiguity relating to copying of ECN bits between 'inner' and 'outer' datagrams. MASQUE is not strictly IP-in-IP, though it's close to it, so it's not clear if RFC 6040 applies. Nevertheless, I would propose the following principles: ECN markings on the MASQUE connection SHOULD NOT be copied to any resulting UDP datagrams sent by the proxy; they should apply to the MASQUE connection only. If MASQUE congestion control is disabled per section 9, it MUST mark all packets non-ECT. ECN markings on incoming UDP datagrams SHOULD NOT be copied to the IP headers of MASQUE packets that encapsulate them: upstream congestion should not affect the congestion state of the MASQUE connection. I'm happy to write a PR to that effect.
When using CONNECT-UDP without extensions, the server-facing UDP sockets on the proxy will not be configured to use ECN, so there will not be any ECN markings on the proxy-server path. In other words, ECN will not be in use, so do we need text about it? Adding text to clarify this sounds reasonable, but it probably should be generic to anything in the IP header.
The extensions explicitly concern markings on DATAGRAM frames in the inner connection. The server may very well be sending packets with ECT(0). With no extension, it will eventually stop, but nevertheless these shouldn’t appear in MASQUE IP headers.
Agreed. I'll take you up on your offer to write a PR then :)
Yes, I think that being clear that for this case the two legs needs to be kept seperate unless internal signalling is used on client to proxy leg to influence the external side setting and receiving of these values.
Thanks!
Change:
format in the first place.  The relevant media type indicator is included in the Content-Type (ct=) attribute. <ins> 4.6. SenML can also be used for configuring parameters and controlling actuators.  When a SenML Pack is sent (e.g., using a HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given resources (names) to given values at the given time(s). </ins> 5. The SenML labels (JSON object member names) shown in tbl-json-labels

Discussion:
Added descriptive text about configuration/actuation usage
Addressing issue
Should there be explanation of the configuration usage?
This looks good to me. Two little tweeks but if you don't like them, I can live with it as it is.
Change:
Application secret is used to bind the Application messages with the next key and add some freshness. <del> [[OPEN ISSUE: The HKDF context field is left empty for now.  A proper security study is needed to make sure that we do not need more </del> <ins> [[ OPEN ISSUE: The HKDF context field is left empty for now.  A proper security study is needed to make sure that we do not need more </ins> information in the context to achieve the security goals.]] [[ OPEN ISSUE: At the moment there is no contributivity of

Discussion:
Clean up some OPEN ISSUES that aren't open any more Make the welcome/add diagram clearer
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - 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:
"Media" refers to any type of media and associated streams such as video, audio, metadata, etc. <del> 1.1. </del> <ins> "Over the Internet" means that a single operator does not have control of the entire path between media servers and media clients, so not a "walled garden". 1.2. </ins> A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
having the resource check that requests have the same string in their "url" fields. <del> 5.3.1. </del> <ins> 5.4.1. </ins> The "url" header parameter specifies the URL to which this JWS object is directed RFC3986.  The "url" parameter MUST be carried in the protected header of the JWS.  The value of the "url" header MUST be a JSON string representing the URL. <del> 5.4. </del> <ins> 5.5. </ins> In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism

Discussion:
As discussed (too ambiguously) at IETF 96, this refactor uses two nested JWS objects instead of one parallel JWS object. This preserves the pattern that every ACME message sent by the client is signed by exactly one account key, and saves clients from having to search through multiple signatures in the verification process.
Looking at the current mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now: It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key. Both signatures have to include the parameter, so this request burns two nonces unnecessarily The server's JWS checking code now has to switch between validating one signature and two Lots of JWS implementations don't support multiple signatures If not for this, we could require the flattened JSON serialization You need a lot of duplication to deal with the copy/paste attacks (cf. ). (On the other hand, I like that both signatures cover the parameter; reduces replayability.) I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.
Just noticed that if we keep to one signature per object, you can do nice stuff like this on the server:
Change:
protocol, and perform the reverse conversion on the messages it receives from the other side. <del> One way to mitigate this is to provide a JavaScript library that hides this complexity from the developer; said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher level call-oriented interface to the application developer.  For example, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </del> <ins> One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher level call-oriented interface to the application developer.  For example, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </ins> 1.2.

Discussion:
Last paragraph on page 5 - first sentence: at "One way to mitigate this" - "this" has an unclear antecedent. Did you mean "One way to reduce the complexity of the application's responsibilities"?
Agreed. Editorial
Change:
All trees used in this protocol are left-balanced binary trees.  A binary tree is _full_ (and _balanced_) if its size is a power of two and for any parent node in the tree, its left and right subtrees have <del> the same size.  If a subtree is full and it is not a subset of any other full subtree, then it is _maximal_. </del> <ins> the same size. </ins> A binary tree is _left-balanced_ if for every parent, either the parent is balanced, or the left subtree of that parent is the largest full subtree that could be constructed from the leaves present in the parent's own subtree.  Given a list of "n" items, there is a unique left-balanced binary tree structure with these elements as leaves. <del> In such a left-balanced tree, the "k-th" leaf node refers to the "k-th" leaf node in the tree when counting from the left, starting from 0. </del> (Note that left-balanced binary trees are the same structure that is used for the Merkle trees in the Certificate Transparency protocol I-

Discussion:
I've put a bunch of little fixes in here. If you disagree with any of these changes, I can back them out or change them. maximal is defined but never used k-th leaf/leaf index is defined in two places; merge definitions change KeyPackage struct definition to reflect that ~2~ 3 extensions are required is also a required extension grammar fix add missing semicolon
One minor thing, otherwise LGTM
Change:
9.4. <del> Consider that "request-quota" may not be restored after the moment </del> <ins> Consider that "service-limit" may not be restored after the moment </ins> referenced by "RateLimit-Reset", and the "RateLimit-Reset" value should not be considered fixed nor constant.

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:
TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, much of Section 2.1 <del> of RFC5216 does not apply for TLS 1.3. </del> <ins> of RFC5216 does not apply for TLS 1.3.  EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 RFC5216 . TLS version negotiation is handled by the TLS layer, and thus outside of the scope of EAP-TLS. Therefore so long as the underlying TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. </ins> After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS

Discussion:
The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge
Change:
retransmissions and may result in degraded performance due to the actions of the congestion controller upon detecting loss. Implementations can detect spurious retransmissions and increase the <del> reordering threshold in packets or time to reduce future spurious </del> <ins> packet or time reordering threshold to reduce future spurious </ins> retransmissions and loss events.  Implementations with adaptive time thresholds MAY choose to start with smaller initial reordering thresholds to minimize recovery latency.

Discussion:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!
Change:
Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version.  The <del> protocol specified here will receive a version number other than 2 from IANA. Discussion of this work is encouraged to happen on the QUIC IETF mailing list <quic@ietf.org> or on the GitHub repository which contains the draft: <https://github.com/quicwg/quic-v2>. </del> <ins> protocol specified here uses a version number other than 2 in the wire image. </ins> 1.

Discussion:
, ,
It would be nice to have the references use a consistent format (e.g. all having a name instead of the RFC number for some)
OK, I've only left document number references where the subject is indicated beforehand, e.g. Alt-Svc {{?RFC7838}}
fixed by
Draft currently states: This repeats the QUIC VN document, should we remove it?
Yes, good catch.
fixed by
The draft currently says: Could we add a note to be removed by the RFC editor that clarifies whether or not we're going to change the version number before publication or not?
fixed by
The abstract currently contains: I'm pretty sure the second one won't be included, but there's no note saying so. I don't know if the first one is meant to stay. Can we add a note to make this explicit? Markdown can do it for you for the second one.
Actually the second note can be removed entirely because it repeats the paragraph that's autogenerated.
Thanks!
Change:
1. <del> The version-invariant properties of QUIC INV define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. </del> <ins> The version-invariant properties of QUIC QUIC-INVARIANTS define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. </ins> With proper safety mechanisms in place, the Version Negotiation packet can be part of a mechanism to allow two QUIC implementations

Discussion:
editorial nit: for consitency with RFC 9000, consider changing you reference name from [INV] -> [QUIC-INVARIANTS]
Change:
Verify that the contents of one of the TXT records matches the digest value <del> It is RECOMMENDED that the server perform multiple DNS queries from various network perspectives, in order to make MitM attacks harder. </del> If all of the above verifications succeed, then the validation is successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails.

Discussion:
Previously these were spread among the various challenges. We can simplify by putting them in one place. Replaces .