jiebi/CodeConvo huggingface dataset:
Change:
described in credentials. The "capabilities" field indicates what protocol versions, <del> ciphersuites, protocol extensions, and non-default proposal types are supported by a client.  Proposal types defined in this document are considered "default" and thus need not be listed.  Extensions that appear in the "extensions" field of a LeafNode MUST be included in the "extensions" field of the "capabilities" field. </del> <ins> ciphersuites, extensions, credential types, and non-default proposal types are supported by a client.  Proposal and extension types defined in this document are considered "default" and thus need not be listed, while any credential types the application wishes to use MUST be listed.  Extensions that appear in the "extensions" field of a LeafNode MUST be included in the "extensions" field of the "capabilities" field, and the credential type used in the LeafNode MUST be included in the "credentials" field of the "capabilities" field. </ins> The "leaf_node_source" field indicates how this LeafNode came to be added to the tree.  This signal tells other members of the group

Discussion:
This PR adds a way for the members of a group to indicate the credential types they support, and how to negotiate which credential types may be used in a group.
I discussed this offline with NAME and we arrived at: We might need multiple credentials later (as I suspect) If we do that (say in an extension), we will need to update this text We should capture the general theory that covers both single- and multiple-credential cases The proposed additions here just abstract the principle of universal compatibility (which we need in a single-credential world) to one of "at least something" compatibility (which is more compatible with a multi-credential world).> The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group. If you agree with the concept, I am happy to propose slight changes.I think this makes sense.
Change:
any time by using the following call on the Connection object: Note that most properties are only considered for connection <del> establishment and can not be changed later on. appendix-specify- query-params gives an overview of what Transport Parameters can be specified and queried during which phase. </del> <ins> establishment and can not be changed after a connection is established; however, they can be queried.  See introspection. </ins> A Connection gets its Transport Parameters either by being explicitly configured via a Preconnection, or by inheriting them from an

Discussion:
Appendix B of the API draft provides a sample concrete definition of the API, written in Go. Having concrete examples of the API is clearly useful, but I question whether this draft is the right place for them, since we don't want to bless a particular API variant. Suggest this appendix be moved to either the implementation draft, or a separate example API implementation draft.
The intention here is to show that the API is reasonably expressible and expressive in at least one modern language. I'd be more than happy to replace it with links to the code and documentation for now though. (Eventually, examples would be more useful than the sketch though.)
NAME makes sense.
Looks good to me.Looks good to me
Change:
Captive Portal Conditions: site-specific requirements that a user or device must satisfy in order to gain access to the wider network. <del> Captive Portal Enforcement: The network equipment which enforces the traffic restriction. </del> <ins> Captive Portal Enforcement Device: The network equipment which enforces the traffic restriction.  Also known as Enforcement Device. </ins> Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of

Discussion:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?
Change:
at the same spot in the video for all players playing the segment delivered from that cache node. <del> 2.4. </del> <ins> 2.5. </ins> Historical data shows that users consume more video and videos at higher bitrates than they did in the past on their connected devices.

Discussion:
This definitely needs more work!
NAME and NAME - I have three notes in the section I've added. I'll hit this again later in the week, but if you can express opinions about any of them, that would be very helpful.
NAME In the call we discussed this and we feel like we don't need to say anything about this in addition to what we already said in Section titled "Bitrate Detection Challenges". So, maybe we can drop and close this?
I actually like NAME suggestions - let me spend a couple of hours on this, and then you two can either merge it or reject it.
NAME and NAME see what you think. I'm also ok with closing as wontfix, but wanted to give it a try.
NAME and NAME any thoughts on this PR? I tried to reflect Jake's high-level comments, which were even more helpful and actionable than usual ...
This reads much better than the initial version, thanks.
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Mark Nottingham) in response to call for help on capturing the mismatch between supply and demand of bandwidth with regard to video: Dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) "These are big numbers, but the internet has grown over time, and CDN capacities have grown over time. Is it last mile? Probably not--Is it middle mile? Maybe that's more interesting. It it CPU? Is it network cards? Is it the economics of your peering relationships? Unpicking those bits might help a bit. URL
For many, poor Wifi is the culprit. For many others, the ISP aggregation links are the culprit during the prime times (since most such links are oversubscribed/oversold). For some, the CDN issues create problems and for rare cases, the origin drowns and everybody gets upset. For certain environments like student dorms, campus networks, libraries, airport cafes, it is just lack of bandwidth for the power users.
Thanks, this version reads much better to me. I have no objections.
Change:
MUST be parsed as described in RFC4566, Section 6, and its value stored. <del> Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as specified in RFC5576, Sections 4.1-4.2, and their values stored. </del> <ins> Any "a=ssrc" attributes MUST be parsed as specified in RFC5576, Section 4.1, and their values stored. </ins> Any "a=extmap" attributes MUST be parsed as specified in RFC5285, Section 5, and their values stored.

Discussion:
removes parsing of a=ssrc and a=ssrc-group. The createOffer parts were removed in the -17 draft.
Wouldn't it make more sense to add the ssrc-group back into the draft to allow proper handling of RTX.
I'm fine with removing this
Not sure why we need to remove this since this can be used to indicate how to init the demux table.
I do think removing ssrc-group would be a good idea though since we don't plan to use it. We should also make clear that a=ssrc is only used for seeding the demux table.
To be specific: 5.9 (remote desc) should be updated to indicate that any a=ssrc values are supplied to the demuxer, and we should remove discussion of a=ssrc-group here.
You arguments to keep this make sense. I'm fine with keeping it.
Changed it to only remove a=ssrc-group, since IIUC the demux algorithm does not consider it. NAME does this seem reasonable to you? Separately I will add text in 5.9 to say that the a=ssrc values should be supplied to the demuxer.
It was non-obvious to me that RTX has to use the same MID RTP header extension values as the RTP stream it covers. Now the same argument for priming the demuxer could be made for the SSRC learned from ssrc-group. But if we assume that RTX packets will not be the first packets which you receive it's probably fine.
Remaining task from
Change:
origination.  (One cannot, for example, be used to prove the identity of the sender to a third party.) <ins> MACs are designed in the same basic structure as signature with appendix algorithms.  The message content is processed and an authentication code is produced, the authentication code is frequently called a tag.  The basic structure becomes: </ins> MAC algorithms can be based on either a block cipher algorithm (i.e. AES-MAC) or a hash algorithm (i.e.  HMAC).  This document defines a MAC algorithm for each of these two constructions.

Discussion:
Add more intro text to algorithms Put in a note about the fact that a zero length map is not the preferred encoding for the protected field, but is a legal one.
Change:
information.  However, SDP allows many types of lines, not all of which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct <del> according its defining ABNF, check that it conforms to RFC4566 and </del> <ins> according to its defining ABNF, check that it conforms to RFC4566 and </ins> RFC3264 semantics, and then either parse and store or discard the <del> provided value, as described below.  A partial list of ABNF definitions for SDP attributes can found in: </del> <ins> provided value, as described below. </ins> <del> [TODO: ensure that every line is listed below.] If the line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description. This ensures that implementations do not accidentally misinterpret ambiguous SDP. </del> <ins> If any line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description, even if the value is to be discarded.  This ensures that implementations do not accidentally misinterpret ambiguous SDP. </ins> 5.7.1.

Discussion:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)
Change:
configuration over unencrypted DNS is not possible.  This includes Unencrypted Resolvers on private IP addresses RFC1918, Unique Local Addresses (ULAs) RFC4193, and Link Local Addresses RFC3927 RFC4291, <del> whose identity cannot be confirmed using TLS certificates. </del> <ins> whose identity cannot be confirmed using TLS certificates under most conditions. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver

Discussion:
But all bets are off with trust anchors outside of the WebPKI. (Plus a small tweak to the next paragraph.)
Change:
this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the Web Push protocol RFC8030, but it could be used in other contexts if applicable. </del> <ins> server when using the Web Push protocol RFC8030. </ins> 3.1.

Discussion:
This looks a lot worse than it really is. Reflowing text causes massive diffs, which github somehow manages to make look like entirely new text.
Change:
3. <ins> 3.1. After negotiating the use of this extension, clients initiate one or more WebTransport Connect streams to a Http2Transport Server. </ins> Http2Transport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 <del> respectively).  Http2Transport uses the extended CONNECT handshake to negotiate a new upgrade token, "webtransport".  It also defines an HTTP/2 extension that introduces a new frame, "WTHEADERS", which allows for bidirectional communication between the WebTransport server and the client, and it introduces a new HTTP/2 SETTINGS parameter to negotiate the use of the "WTHEADERS" frame. </del> <ins> respectively).  The client uses the extended CONNECT method with a :protocol token "webtransport" to establish a WebTransport Connect Stream.  This stream is only used to establish a WebTransport session and is not intended for data exchange. </ins> <del> 3.1. </del> <ins> 3.2. Following the establishment of a WebTransport Connect stream, either the client or the server can initiate a WebTransport Stream by sending the "WTHEADERS" frame.  This frame references an open WebTransport Connect stream, which is used by any intermediaries to correctly forward the stream to the destination endpoint.  The only frames allowed on WebTransport Streams are WTHEADERS, CONTINUATION, DATA and any negotiated extension frames. 3.3. Clients negotiate the use of WebTransport ove HTTP/2 using both the SETTINGS frame and one or more extended CONNECT requests as defined in RFC8441. </ins> <del> Use of the extended CONNECT method extension defined in RFC8441 requires the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client prior to its use.  An endpoint that supports receiving the extended CONNECT method SHOULD send this setting with a value of 1. </del> <ins> Use of the extended CONNECT method extension requires the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client prior to its use.  An endpoint that supports receiving the extended CONNECT method SHOULD send this setting with a value of 1. </ins> The extended CONNECT method extension uses the ":protocol" psuedo- header field to negotiate the protocol that will be used on a given

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
to make the determination based upon the identity presented by the pledge. <del> While a Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer there are no restrictions on how the Cloud Registrar is horizontally (many sites) or vertically (more equipment at one site) scaled.  It is also entirely possible that all devices sold by through a particular VAR might be preloaded with a configuration that changes the Cloud Registrar URL to point to a VAR.  Such an effort would require unboxing each device in a controlled environment, but the </del> <ins> A Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer.  This document places no restrictions on how many different deployments or owner sites the Cloud Registrar can handle, or how many devices per site that the Cloud Registrar can handle.  It is also entirely possible that all devices sold by through a particular Value Added Reseller (VAR) might be preloaded with a configuration that changes the Cloud Registrar URL to point to a VAR.  Such an effort would require unboxing each device in a controlled environment, but the </ins> provisioning could occur using a regular BRSKI or SZTP RFC8572 process.

Discussion:
[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?
Change:
Many different attacks have been reported as part of revelations associated with pervasive surveillance.  Some of the reported attacks <del> involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Such attacks are conceivable, for instance, during the manufacturing process of cards, or during the transfer of cards and associated information to the operator.  Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved. </del> <ins> involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards.  Such attacks are conceivable, for instance, during the manufacturing process of cards, or during the transfer of cards and associated information to the operator. Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved. </ins> However, the danger of resourceful attackers attempting to gain information about SIM cards is still a concern.  They are a high-

Discussion:
Not sure the attacks actually attacked the smart cards. Changed to "smart card supply chain" in the abstract and intro. This is very much related to zero trust principles. added a sentence about this. Any modern standard track EAP method should provide mandatory client identity protection. Copied the text from EAP-TLS 1.3 Motivation for the chosen curves is missing. Added link to the definition of SUCI encryption in appendix C.3.4. of TS 33.501 Added more text in security consideration on the attacks an attacker can do. Added more text in security consideration on frequent use of ECDHE.
Great! There's one typo but I'll fix it.
Change:
5. <del> There are multiple possible models for communication between an Attester, a Verifier, and a Relying Party.  This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist. </del> <ins> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester sends its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Results from the Verifier.  There are multiple other possible models.  This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist. </ins> 5.1.

Discussion:
describe the basic Topological Model without complicating the draft
I am uncertain about the state of this PR. NAME were your comments addressed?
~ In both the passport and background-check models, the Attester communicates directly with the Relying Party to access some resources. But in some cases, the Attester doesn't need to access resources from the Relying Party. Assume that the Attester is a network device (router, switch, etc.), and the Relying Party is the network management system (NMS) of the network operator. In such a case, the NMS monitors the health of the device by retrieving the Attestation Result of the device from a Verifier. If the device fails the attestation process, the NMS can take countermeasures like quarantining it. So the figure above depicts this situation.
Is this topological model covered by the passport model or background-check model?
The above flow is always the information flow. The passport model and background-check are models for how the conveyance works.
Also, we had that diagram in the architecture documents, and we have the above diagram as figure 1 already.
This is also a way in which the conveyance can work. I add two sentences to describe this basic one without duplicating the diagram.
We conclude that there is not a need for this additional topological flow.
Change:
4.2.3. <del> The ROUTE_ADVERTISEMENT capsule allows an endpoint to communicate to its peer that it is willing to route traffic to a given prefix.  This indicates that the sender has an existing route to the prefix, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del> <ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it is willing to route traffic to a given prefix.  This indicates that the sender has an existing route to the prefix, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route.  Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule. </ins> IP Version of this route advertisement.  MUST be either 4 or 6.

Discussion:
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
Change:
A QUIC server starts the process by providing TLS with the client's handshake bytes. <del> At any given time, the TLS stack at an endpoint will have a current sending encryption level and receiving encryption level.  Each encryption level is associated with a different flow of bytes, which is reliably transmitted to the peer in CRYPTO frames.  When TLS provides handshake bytes to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. </del> <ins> At any time, the TLS stack at an endpoint will have a current sending encryption level and receiving encryption level.  Each encryption level is associated with a different flow of bytes, which is reliably transmitted to the peer in CRYPTO frames.  When TLS provides handshake bytes to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. </ins> QUIC takes the unprotected content of TLS handshake records as the content of CRYPTO frames.  TLS record protection is not used by QUIC. QUIC assembles CRYPTO frames into QUIC packets, which are protected using QUIC packet protection. <ins> QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS alerts are turned into QUIC CONNECTION_CLOSE error codes; see tls-errors.  TLS application data and other message types cannot be carried by QUIC at any encryption level and is an error if they are received from the TLS stack. </ins> When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows:

Discussion:
This is a point NAME makes in , but it probably pays to make it more clearly. This was possible in earlier iterations of the draft, so it's worth stamping out residual mentions.
Section 4.5 of quic-tls: Early data within the TLS connection MUST NOT be used. As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. As there is no way to express TLS application data (no record headers!) I believe there is no way for the proposed error condition to occur. I propose we strike the paragraph, though we might mention that this condition is impossible for clarity.