jiebi/CodeConvo huggingface dataset:
Change:
match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any group resource that endpoint is contained in.  Queries for resource <del> link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </del> <ins> link targets MUST be in URI form (ie. not relative references) and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
ciphersuite for a credential in a KeyPackage object.  For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using ECDSA <del> with the NIST curves P-256 or P-521, the public key is the output of the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. </del> <ins> with the NIST curves (P-256, P-384, or P-521), the public key is the output of the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. </ins> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the

Discussion:
The following statement is no longer up-to-date, given addition of P-384: "For ciphersuites using ECDSA with the NIST curves P-256 or P-521, the public key is..." To avoid tracking too many changes in the future for the document, I suggest the simple edit: "For ciphersuites using ECDSA with the NIST curves, the public key is..."
Change:
in the log. This is done with an HTTP GET using the operation path value of <del> "/requestauditlog". </del> <ins> "/.well-known/est/requestauditlog". </ins> The Registrar MUST HTTP POSTs the same Registrar voucher-request as it did when requesting a Voucher.  It is posted to the

Discussion:
Proposes 201/Location: operation optional for /requestauditlog end-point.
Think we should discuss.
Change:
packets preceding the Largest Acknowledged that are being acknowledged.  The First ACK Range is encoded as an ACK Range (see ack-ranges) starting from the Largest Acknowledged.  That is, the <del> smallest packet number included in the range is determined by </del> <ins> smallest packet acknowledged in the range is determined by </ins> subtracting the First ACK Range value from the Largest Acknowledged. <del> Contains additional ranges of packet numbers which are alternately not acknowledged (Gap) and acknowledged (ACK Range), see ack- ranges. </del> <ins> Contains additional ranges of packets which are alternately not acknowledged (Gap) and acknowledged (ACK Range), see ack-ranges. </ins> The three ECN Counts, see ack-ecn-counts.

Discussion:
Packets are acknowledged, though packet numbers are communicated to acknowledge them.
One high-level comment. I believe the intent was to move most of the text about sending ACKs from recovery to transport. Also, if we defined ack-eliciting in transport, I think this PR and some other text would read more clearly. I can do that in a follow up PR.
Thanks for cleaning this up. One more TODO down.
Change:
7.1. <del> TODO - Add text to explain how to use RTX as described in Option A of slides presented at IETF 99. </del> <ins> When using RTX RFC4588 with double, the cached payloads MUST be the encrypted packets with the bits that are sent over the wire to the other side.  When encrypting a retransmission packet, it MUST be encrypted using a crypto context with a null E2E key. </ins> 7.2.

Discussion:
This is not ready to merge yet but can be used to start discussion on RTX text
Higher level question .. Should it help having a generic repair processing section that identifies the sender and receiver behavior. It could be informative and can reflect the pictures from the presentation. Thoughts ?
I think as confusing as the whole topic is/was to us experts I think we should have a paragraph explaining that any of the repairs are effectively a triple encryption.
looks good
Change:
identifies the frame.  These frames are explained in more detail in frame-formats. <del> All QUIC frames are idempotent.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </del> <ins> All QUIC frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </ins> The Frame Type field uses a variable length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient

Discussion:
Is this just a statement about this spec or a normative requirement on future specs?
It is not an invariant.
There's more to requirements on future specs than invariants.
It's a statement about the current version, but it would presumptively apply to extensions to the current version that don't redefine the base spec.
Perhaps it'd be better to use to avoid confusion like this.
Change:
PUSH_PROMISE frames are not part of the response; see server-push for more details. <ins> The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic table.  While these updates are not directly part of the message exchange, they must be received and processed before the message can be consumed.  See header-formatting for more details. </ins> The "chunked" transfer encoding defined in Section 4.1 of RFC7230 MUST NOT be used.

Discussion:
This arises from a different discussion I had about the message exchange definition in section 5.1. The description is correct but glosses over the detail of QPACK, which is mentioned very briefly later in section 5.1.1. For complete accuracy, I would argue that a single message exchange may also contain one or more QPACK encoder instructions sent on the encoder stream.
Change:
In this process, the joiner sends a new "init_secret" value to the group using the HPKE export method.  The joiner then uses that <del> "init_secret" with information provided in the PublicGroupState and an external Commit to initialize their copy of the key schedule for the new epoch. </del> <ins> "init_secret" with information provided in the GroupInfo and an external Commit to initialize their copy of the key schedule for the new epoch. </ins> Members of the group receive the "kem_output" in an ExternalInit proposal and preform the corresponding calculation to retrieve the "init_secret" value. <del> In both cases, the "info" input to HPKE is set to the PublicGroupState for the previous epoch, encoded using the TLS serialization. </del> <ins> In both cases, the "info" input to HPKE is set to the GroupInfo for the previous epoch, encoded using the TLS serialization. </ins> 9.4.

Discussion:
PublicGroupState was removed as an independent struct in . This PR fixes some dangling references to it.
cc NAME
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Also, update WireFormat: s/mlspublicgroupstate(4),/mlsgroup_info(4),/
Change:
4. <del> [EDITOR'S NOTE: write three paragraph summary here; see https://github.com/taps-api/drafts/issues/93] </del> <ins> The Transport Services Interface is the basic common abstract application programming interface to the Transport Services Architecture defined in TAPS-ARCH.  An application primarily interacts with this interface through two objects, Preconnections and Connections.  A Preconnection represents a set of parameters and constraints on the selection and configuration of paths and protocols to establish a connection with a remote endpoint.  A Connection represents a transport protocol stack on which data can be sent to and received from a remote endpoint.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client), through listening on the Preconnection (i.e., passively opening, as in a server), or rendezvousing on the Preconnection (i.e. peer to peer establishment). Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message boundaries both via explicit protocol stack support, and via application support through a deframing callback which finds message boundaries in a stream.  Messages are received asynchronously through a callback registered by the application.  Error and other notifications also happen asynchronously on the Connection. </ins> In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of <del> a connection, following the phases described in TAPS-ARCH. </del> <ins> a connection, following the phases described in TAPS-ARCH.  An example interface sketch in Go is shown in appendix-api-sketch. </ins> 5.

Discussion:
There are still a few s and similar scattered throughout the document. Find them and fix them, or move them to post-London issues.
Change:
Operational Considerations for Streaming Media <del> draft-ietf-mops-streaming-opcons-03 </del> <ins> draft-ietf-mops-streaming-opcons-latest </ins> Abstract

Discussion:
…nd update public discussion venues
I left the previous description of Sanjay Mishra's presentation, but removed the sub-references in that description (which included the problematic ATT reference).
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?
Change:
8. QUIC uses the TLS handshake for more than just negotiation of <del> cryptographic parameters.  The TLS handshake validates protocol version selection, provides preliminary values for QUIC transport parameters, and allows a server to perform return routability checks on clients. </del> <ins> cryptographic parameters.  The TLS handshake provides preliminary values for QUIC transport parameters and allows a server to perform return routability checks on clients. </ins> 8.1.

Discussion:
I'm pretty sure this was obsoleted when version negotiation was removed (along with initial/negotiated/supported versions from transport parameters). If you think the TLS handshake is still validating protocol version selection, feel free to reject this PR.
Change:
It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation <del> and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the </del> <ins> and sequencing of PSK callbacks influences the application's behavior when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the </ins> application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence

Discussion:
cc NAME NAME
In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations that can be made? In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance. Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe.
Change:
The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows. <del> The "ECHConfigs" structure contains one or more "ECHConfig" </del> <ins> The "ECHConfigList" structure contains one or more "ECHConfig" </ins> structures in decreasing order of preference.  This allows a server to support multiple versions of ECH and multiple sets of ECH parameters.

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
The client then constructs an encapsulated request, "enc_request", as follows: <del> Compute an HPKE context using "pkR", yielding "context" and encapsulation key "enc". </del> <ins> Compute an HPKE context using "pkR" and a label of "ohttp request", yielding "context" and encapsulation key "enc". </ins> Construct associated data, "aad", by concatenating the values of "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and

Discussion:
This is a breaking change, but I think that it's worthwhile. "request" is an extraordinary generic string and the risk of it being used in another context is too high.
We can address test vectors in a followup PR.
Change:
may now use this in the same way as if he had gotten it from a new- registration transaction. <del> 6.5. </del> <ins> 6.6. </ins> The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This

Discussion:
What advantage does including the old key provide?
Having the new key sign over the field makes the hand-over mutual -- the old key blesses the new key by signing over the JWS and the new key accepts by signing over the thumbprint. Basically, the field is acting as an identifier for the registration for purposes of the new key's acceptance of the hand-over. Note that this is well-defined because the server is required to only have one registration for a given key-pair (it MUST return a 409/Conflict if there's an attempt to duplicate).
Account keys should change over time to improve security. We should have a way to change the key associated with an account with changing anything else about the account. Something liike: Post: /rotate-key { "key": { / JWK key / } } Note: The request should be signed with the old key. All authorizations should remain with the account. If there are any requests being validated then they should still use the old key (as specified by the oriignal authorization request.
Change:
Gateway Resource also act as HTTP clients toward the Oblivious Gateway Resource and Target Resource respectively. <ins> In order to achieve the privacy and security goals of the protocol a client also needs to observe the guidance in client-responsibilities. </ins> The Oblivious Relay Resource interacts with the Oblivious Gateway Resource as an HTTP client by constructing a request using the same restrictions as the client request, except that the target URI is the

Discussion:
So add some forward references.
Sections 6.1, 6.2 and 6.3 detail normative requirements that seem to apply to the actors duties outlined in section 5. Consider forward references to each respective section to aid implementers in discovery applicable considerations.
Change:
records in referrals.  If message size constraints prevent the inclusion of all glue records in a UDP response, the server MUST set the TC flag to inform the client that the response is incomplete, and <del> that the client SHOULD use TCP to retrieve the full response. </del> <ins> that the client SHOULD use TCP to retrieve the full response.  This document updates RFC 1034 to clarify correct server behavior. </ins> 1.

Discussion:
For issue .
A colleague asked me to clarify that the document applies only to name server behavior, and does not place any requirements on how zones or registries are populated. i.e., we are not saying that "glue is not optional" for delegations in a zone.
This was done with commit 45cb8efcbf03c193791a14894aeb8d9d2a15096e
Change:
when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. <del> The connection ID to be used for a long-running flow is chosen by the server (see QUIC-TRANSPORT section 5.6) during the handshake.  This value should be treated as opaque; see sec-loadbalancing for caveats regarding connection ID selection at servers. </del> <ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is encrypted, packets with the same 5-tuple but different connection IDs may or may not belong to the same connection. The connection ID value should be treated as opaque; see sec- loadbalancing for caveats regarding connection ID selection at servers. </ins> 3.5.

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.
Change:
element or member value as the filter selector iterates over the array or object. <del> 3.4.8.2.1. </del> <ins> 3.4.7.2.1. </ins> A singular path by itself in a Boolean context is an existence test which yields true if the path selects a node and yields false if the

Discussion:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!
Change:
2.6.1. <del> Each parameter and the result of a function extension must have a declared type. </del> <ins> Each parameter as well as the result of a function extension must have a declared type. </ins> A type is a set of instances.  Declared types enable checking a JSONPath query for well-typedness independent of any argument the

Discussion:
These editorial changes from PR are needed in the base.
I confess I tend to write tedious text when precision is at stake. Hopefully, the second commit avoids the tedium.
Why was this merged so quickly?!
We merged this editorial change quickly so we could rebase the other substantive PRs on it and put us in a better position to compare their pro's and con's.
Looks good now! Should merge this quickly so we can rebase the others.
Change:
A TSN-aware IP (DetNet) node implementations MUST support the Sequencing function and the Sequence encode/decode function as <del> defined in IEEE8021CB if FRER is used inside the TSN sub-network. </del> <ins> defined in Clause 7.4 and 7.6 of IEEE8021CB if FRER is used inside the TSN sub-network. </ins> The Sequence encode/decode function MUST support the Redundancy tag (R-TAG) format as per Clause 7.8 of IEEE8021CB. A TSN-aware IP (DetNet) node implementations MUST support the Stream splitting function and the Individual recovery function as defined in <del> IEEE8021CB when the node is a replication or elimination point for FRER. </del> <ins> Clause 7.7 and 7.5 of IEEE8021CB when the node is a replication or elimination point for FRER. </ins> 4.3. TSN Streams supporting DetNet flows may use Frame Replication and <del> Elimination for Redundancy (FRER) as defined in IEEE8021CB based on the loss service requirements of the TSN Stream, which is derived from the DetNet service requirements of the DetNet mapped flow.  The specific operation of FRER is not modified by the use of DetNet and follows IEEE8021CB. </del> <ins> Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE8021CB based on the loss service requirements of the TSN Stream, which is derived from the DetNet service requirements of the DetNet mapped flow.  The specific operation of FRER is not modified by the use of DetNet and follows IEEE8021CB. </ins> FRER function and the provided service recovery is available only within the TSN sub-network as the TSN Stream-ID and the TSN sequence

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)