jiebi/CodeConvo huggingface dataset:
Change:
it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446. <ins> This document also defines an ASN.1 module for the DelegationUsage certificate extension in module.  IANA is requested to register an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX Module Identifier" arc.  An OID for the DelegationUsage certificate extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. </ins> 5. 5.1.

Discussion:
I suspect at some point somebody would have asked for an ASN.1 module. I know not everybody uses an ASN.1 compiler, but some do. I also know Russ Housley was going through an making for all of the RFCs that include ASN.1. He also double checked that the ASN.1 module compiles (if you put a dummy OID in for the TBD it will compile). An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections.
"An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections." Are you thinking of getting a different OID for the DCs, does the cf OID not work?
Sean is talking about the Module Identifier. The CF OID inside the module is fine.
The CF OID for the extension works just fine - in fact I should have left the sentence in the PR explaining that. We need an OID for the ASN.1 module (TBD). Technically, I guess we do not need an OID if CF has an ASN.1 module already. But, I suspect there wasn't an ASN.1 module. Make sense?
NAME do you know if CF has an ASN.1 module already?
since noone seems to have any objections, merging away.
Not having an ASN.1 module for the certificate extension has bit us in the a** before. I will make one and add it in as an appendix.
Change:
in the Handshake Key Schedule to be ease chaining in case we switch design. (*) <ins> Added an appendix with example code for tree math </ins> draft-00 Initial adoption of draft-barnes-mls-protocol-01 as a WG item.

Discussion:
The math for left-balanced binary trees is very reliable once you have it right, but can be hard to get right from scratch. This PR provides an appendix that explains a theory and code for managing these trees.
I feel this is very useful to have in the draft for implementors. What should be the plan to merge it ? NAME
Thanks ! I expect that it's going to be very useful for implementers. I am trusting that it is correct Python syntax ;) Pointed out a potential typo in the comments.
Change:
cost, uninterrupted services, privacy and security, for IoT services originated from the IoT environmental changes.  In order to address those new challenges, the integration of Edge computing and IoT has <del> been emerged as a promising solution.  This document discribes the concept of IoT integrated with Edge computing as well as the state- of-the-art of IoT Edge computing.  It also proposes an architecture of IoT Edge computing.  The direction of Edge computing for IoT should be discussed in the IETF/IRTF. </del> <ins> emerged as a promising solution.  This document describes the concept of IoT integrated with Edge computing as well as the state-of-the-art of IoT Edge computing.  It also proposes a general model for IoT Edge computing.  The direction of Edge computing for IoT should be discussed in the IETF/IRTF. </ins> 1.

Discussion:
Main change: Merged 2 sections (IoT Integrated with Edge Computing and architecture section) into a new "model" section. Updated the architecture diagram into a model diagram including the logical functions proposed by Dirk. Heavily reworded/simplified text from the previous 2 sections - I tried to keep relevant info, but removed what was redundant with the existing challenges section. The architectures (gateway vs. distributed) are shortly listed above the figure, but the rest aims to be general. Some renaming for your consideration (feel free to ignore/change): new draft title: IoT Edge Computing Challenges, Model and State-of-Art Review challenges section ("new IoT challenges" could seem a bit general): Challenges for IoT and Impacts of Edge Computing Minor: edits in abstract
Yong-Geun, Jungha, and Dirk agreed via e-mail. Since the new version has been sent to the Datatracker, I will merge.
Change:
16.2. The following example illustrates a hypothetical Passport Model <del> solution that uses nonces and thus does not require that any clocks are synchronized. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </del> <ins> solution that uses nonces instead of timestamps.  Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce, and requires that the Verifier and Relying Party track state to remember the nonce for some period of time. The advantage is that it does not require that any clocks are synchronized.  As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps.  Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </ins> In this example solution, the Verifier can check whether the Evidence is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <

Discussion:
Line had the closing "}" in the wrong place in the diagram. While touching this text, added phrase about disadvantage of the nonce approach, to provide more balanced discussion of timestamps vs nonces vs handles. Signed-off-by: Dave Thaler
Change:
characters outside the base64url alphabet, including padding characters ("="). <del> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then computes the SHA-256 digest FIPS180-4 of the key authorization. </del> <ins> A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then computes the SHA-256 digest FIPS180-4 of the key authorization. </ins> The record provisioned to the DNS contains the base64url encoding of this digest.  The client constructs the validation domain name by

Discussion:
Respond with {} instead of providing keyAuthorization Remove "keyAuthorization" from the challenge object returned by the server. Fixes a potential misguide for clients that enabels a MitM attack. Keep the storing of the keyAuthorization on response to retain the same behavior if an account key roll-over happens before the challenge is validated
I like this change in theory, but it's substantive enough that I'd like to give the mailing list a couple more pokes to see if anyone has further thoughts on it before we land it.
This is not an editorial change, and I think it would require pushing back further on last-call timing. Please bring this up and discuss on the mailing list; WG consensus will be required.
This was brought up on the list Dec 27th and only positive responses were received.
https://ietf-wg-URL From the spec This is not consistent with the example: Which is posting to . I would expect the example to show has . Also, there is no other mention of present in the example payload. Is this a mistake?
The example is correct. The URL for the challenge is , as shown in the response body above the example you cite: (Note the at the end that distinguishes the challenge from the authz URL ) As for the field, it looks like NAME fixed this in
thanks
This PR looks good to me. I think the proposed change makes sense and removes a potential error without sacrificing anything functionality wise. NAME NAME Can you give this a review as well?
Change:
end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers. <del> 2.6. </del> <ins> 2.7. </ins> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided

Discussion:
The manageability document should illustrate all the various packet sequences in a handshake, preferably with pretty pictures.
Now the transport draft has these illustrations as well. However, I think we should still at them in manageability as well. Actually I would like to try the SVG format here. Anybody in for that?
The handshake illustrations here should only concern themselves with the wire image, unlike those in the transport draft, but yes we should derive them from the transport draft. Happy to do these in ASCII as well as SVG.
The problem with examples is that they might be typical, but they rarely capture the breadth of options well. Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed. For instance, put PADDING first.
Change:
5.8. The following steps are performed at the media engine level to apply <del> a local description. </del> <ins> a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> First, the parsed parameters are checked to ensure that they have not been altered after their generation in createOffer/createAnswer, as

Discussion:
Plan is to write the text in the apply local/remote sections to indicate that upon an error, the session state should be restored to the pre-call state.
Change:
application's data. Connection establishment is divided into two top-level steps: <del> Candidate Gathering, to identify the paths, protocols, and endpoints to use, and Candidate Racing (see Section 4.2.2 of I-D.ietf-taps- arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use. </del> <ins> Candidate Gathering (defined in Section 4.2.1 of I-D.ietf-taps-arch), to identify the paths, protocols, and endpoints to use (see gathering); and Candidate Racing (defined in Section 4.2.2 of I- D.ietf-taps-arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use (see racing).  Candidate Racing involves attempting multiple options for connection establishment, and choosing the first option to succeed as the Protocol Stack to use for the connection.  These attempts are usually staggered, starting each next option after a delay, but they can also be performed in parallel or only after waiting for failures. </ins> For ease of illustration, this document structures the candidates for <del> racing as a tree.  This is not meant to restrict implementations from structuring racing candidates differently. </del> <ins> racing as a tree (see tree-structure).  This is not meant to restrict implementations from structuring racing candidates differently. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,

Discussion:
Raising this issue as part of my review of the the Implementation Draft. To a reader who understands "protocol racing" in the "Happy Eyeballs" sense of near-simultaneous connection establishment attempts, parts of Section 4.1 are confusing. It appears as if "real racing" actually only occurs between Derived Endpoints and not e.g., among Alternate Paths, where we instead have "failover after timeout": Section 4.1.1.2 However, in Section 4.1.1.3 "Protocol Options", the "rank[ing] and attempt[ing]" of options is also referred to as "racing": It seems clear that this kind of information is only useful when connection attempts are not in fact "raced" (nearly) in parallel, but are only conducted in succession, where it makes sense to rank the candidates accordingly. This confusion is only cleared up in Section 4.3, where it says: So it appears as if (in partial departure from the Happy Eyeballs RFC) the term "racing" here is meant to include staggered or failover scenarios, somewhat undermining the original metaphor. Suggestions: Explain the extended scope of the "racing" term earlier Perhaps replace some uses the term "racing" with "failover" or even just "ranking"
Mention that "staggered" is the most common form of racing The main thing with racing is that the first one to succeed wins We should add forward references to sections here: We should also explain in this paragraph that the "Staggered" approach is generally the default for racing, and the first one to finish wins.
LGTM, thanks!
Change:
Flows lack any of the ordering or reliability guarantees of streams. Beyond this, a sender SHOULD ensure that DATAGRAM frames within a <del> single flow are transmitted in order relative to one another.  If multiple DATAGRAM frames can be packed into a single QUIC packet, the sender SHOULD group them by flow to promote fate-sharing within a specific flow and improve the ability to process batches of datagram messages efficiently on the receiver. </del> <ins> single flow are transmitted in order relative to one another. </ins> 3.

Discussion:
in Section 2 "Flow Identifiers" it reads this to me seems to be in conflict with the opening statement if the flow-id is in the DATAGRAM payload, the transport is not supposed to be peeking at it. While it could be a nice (but a bit hacky) optimization in a real-world implementation, I feel like the RFC having it as a SHOULD is not ideal.
In my experience, in order to build a high performance implementation of QUIC, you have to leverage the fact that layers can share information to improve performance. Are you saying that you'd prefer not using SHOULD for this kind of optimization?
I think Luca might have a point. If we consider this as a feature that a transport provides as a service, I don't really know what the service provides. There isn't another transport mechanism that relies on the ordering, or an interoperable aspect (would the other side be able to detect this?). It seems this is an aspect more about the API that QUIC provides, which is going to be a rich field of opportunity. There could be benefits but I don't know if we need to use the SHOULD. We could probably relax the language and try to articulate the benefits or tradeoffs of packetization and frame bundling. For instance, batching might interfere with timeliness, and controlling that might start creeping into prioritisation territory. The more I think about it, the described behaviour about batch processing might assume the receiver behaves a certain way, which might not be true. Therefore this might not be a good default to recommend.
Fair enough. Perhaps we remove this for now, and add guidance once we have more implementation/deployment experience?
I can live with a less drastic edit, leaving the text in draws the reader attention to the idea that packing could be important. I'd be happy to put together an editorial replacement for review, and if we hate it, then drop the concrete recommendation?
Thanks Lucas, you framed it way better than I could. Also I believe that whether shared-fate within a flow is desirable or not may depend on the application.
I came here looking for the same information: Why is fate-sharing desired? Is there some background to this?
I think more implementation and deployment experience would help here.

I can see cases like tunneling IP flows containing TCP where fate sharing is preferable, since it's better to lose two adjacent packets in one flow than one packet each in two flows. But it seems a bit use-case specific? Also, you would expect most TCP segments to be large enough you couldn't put two into a single QUIC packet.
Change:
Regular expression tests can be applied to "string" values only. <ins> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". false, null, true are lower-case only (case-sensitive). </ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).

Discussion:
Thanks, the rebase looks good.
NAME After merging some PRs I fixed a conflict here and then added a commit. PTAL and merge if you are happy.
Change:
The next step is to generate m= sections, as specified in RFC4566, Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped <del> RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </del> <ins> RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection.  If there are no such RtpTransceivers, no m= sections are generated; more can be added later, as discussed in RFC3264, Section 5. </ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m=

Discussion:
NAME as Justin points out, 3264 explicitly authorizes this.
i'm a bit late but... without this, the following sequence of events is always going to happen: createOffer setLocalDescription onicecandidate(null) / icegatheringstatechange(complete) Executing this snippet in Chrome never shows a candidate. Is that the intended behaviour? Also the ice gathering state stays "new"? My confusion about this is probably related to ;-)
I guess if we need to allow empty SPDs (no m-sections) then ICE related events should fire right away as they know that nothing is going to happen any way.
NAME I don't see why any events need to fire, since ICE gathering never starts in the first place and there are no in that case.
I failed to find any text in webrtc-pc or JSEP which indicates that the createOffer() call should fail if no RtpTransceiver or data channel has been added to a PeerConnection. Webrtc-pc contains the following: But section does not seem to contain any wording indicating to treat the absence of any RtpTransceiver and DataChannel as such an failure. I think such a scenario should be treated as a failure, as I fail to see any value in generating an empty offer.
Good observation. Personally, I'm inclined to allow this, unless it's forbidden by 3264 - we would just generate the session-level values with no m= sections.
3264 indicates that this is OK: The offer will contain zero or more media streams (each media stream is described by an "m=" line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. I think we should explicitly mention that this is allowed, but otherwise take no action.
Change:
rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list <del> them as the lowest priority (listed after all other algorithms in the supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </del> <ins> them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </ins> The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a

Discussion:
Criteria for one member structure / non structure is as follows: Non structure: basic type -- not messages nor extensions One member structure: others such as messages or extensions
LGTM
Change:
In Split Mode, the provider is _not_ the origin server for private domains.  Rather the DNS records for private domains point to the <del> provider, but the provider's server just relays the connection back to the backend server, which is the true origin server.  The provider does not have access to the plaintext of the connection.  In principle, the provider might not be the origin for any domains, but as a practical matter, it is probably the origin for a large set of innocuous domains, but is also providing protection for some private domains.  Note that the backend server can be an unmodified TLS 1.3 server. </del> <ins> provider, and the provider's server relays the connection back to the backend server, which is the true origin server.  The provider does not have access to the plaintext of the connection. </ins> 3.2.

Discussion:
Based on comments in Montreal, I believe that the authors no longer intend to document the partial-split configuration.
Change:
WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header with a Bearer token <del> as specified in RFC6750 section 2.1.  WHIP clients MUST implemenent </del> <ins> as specified in RFC6750 section 2.1.  WHIP clients MUST implement </ins> this authentication and authorization mechanism and send the HTTP Authorization header in all HTTP request sent to either the WHIP endpoint or resource. The nature, syntax and semantics of the bearer token as well as how to distribute it to the client is outside the scope of this document. <del> Some examples ot the kind of tokens that could be used are, but are </del> <ins> Some examples of the kind of tokens that could be used are, but are </ins> not limited to, JWT tokens as per RFC6750 and RFC8725 or a shared secret stored on a database.  The tokens are typically made available to the end user alongside the WHIP endpoint url and configured on the WHIP clients. WHIP endpoints and resources COULD perform the authentication and <del> authorization by encoding an authentication token withing the urls for the WHIP endpoints or resources instead.  In case the WHIP client is not configured to use a bearer token the HTTP Authorization header </del> <ins> authorization by encoding an authentication token within the urls for the WHIP endpoints or resources instead.  In case the WHIP client is not configured to use a bearer token the HTTP Authorization header </ins> must not be sent in any request. 4.6.

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.