jiebi/CodeConvo huggingface dataset:
Change:
which is not yet in the tree.  Such elements are added to the tree with the requested priority. <del> When a prioritized element is first created it has a default inital </del> <ins> When a prioritized element is first created, it has a default initial </ins> weight of 16 and a default dependency.  Requests and placeholders are <del> dependent on the root of the priority tree, pushes are dependent on </del> <ins> dependent on the root of the priority tree; pushes are dependent on </ins> the client request on which the PUSH_PROMISE frame was sent. Requests may override the default intial values by including a PRIORTIY frame (see frame-priority) at the beginning of the stream. <del> Pushes and placeholders may be later updated by sending a PRIORITY frame on the control stream. </del> <ins> These priorities can be updated by sending a PRIORITY frame on the control stream. </ins> 5.3.1.

Discussion:
Maybe takes things too far, please discuss.
Draft 17 says If I understand H3 Placeholders correctly, the PRIORITY frame would be used to set their priority too. Perhaps we can say: .
To me it seems that the current text is more accurate. While a PRIORITY frame might use a placeholder to designate the target, what is actually prioritized is the stream that carries the response. The transmission of the placeholder itself is never prioritized.
But the PRIORITY frame contains the Prioritized Element ID field, that allows us to set the priority of Placeholder type.
Yeah, my view is that it is an act of prioritizing a stream by specifying a placeholder ID that maps to the stream. Section 5.3 talks about prioritizing "streams".
That's a good observation, so I'd go further to say that IMO the textual description of H3 prioritisation is not completely aligned with the protocol mechanisms. Cue NAME to tell me I am completely off the mark :)
Also, the table of prioritized element types in seems to be duplicated
The two tables in section 4.2.3 are slightly different.
Correct, I just independently spotted that. Its logical but a bit annoying
makes some basic edits to section 4.2.3, adding Table captions and linking to them from the paragraph above. It reworks 5.3 slightly to reframe the language toward describing a tree of abstract elements but still provides concrete examples of request prioritisation.
Yeah, there was originally one table and I had to split it to accommodate the current design. If anyone sees an elegant way to recombine them, I'm fully supportive.
I thought perhaps make the labels multi line and then combine the last two columns of the second table onto the first. So there would be two colums containing two sub columns each, plus the left most bits column. I don't know the Markdown foo to make that happen though.
NAME My bad. I was confused. I now understand the issue and think that the PR will provide us the necessary fixes.
A comment on this text: we should be prioritizing requests and maybe pushes, not streams.
That's a fair point I'll see if I can incorporate that into the PR
Yes, I like this formulation better.
Change:
This document will include requests to IANA: <del> To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang will be necessary. </del> <ins> To be defined yet.  But keeping up with changes to "ietf-tcg- algs.yang" will be necessary. </ins> 4.

Discussion:
Basically, this fixes typos, grammar, and consistency. And, all above, the TPM 2.0 quote information, which was set to TPMSQUOTEINFO. Actually it is TPM2B_ATTEST. Further Issues to be created.
TPM 2.0 quote information (attestation data) is of type TPM2BATTEST, not TPMSQUOTEINFO. TPMSQUOTEINFO is a sub element of the TPM2BATTEST. In a TPM2Quote operation, the TPM signs a hash of the TPM2BATTEST structure. The signature is of type TPMT_SIGNATURE (just FYI).
Change:
in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to <del> satisfy the criteria.  In rare cases, where a receiver requires a minimum resolution which is greater than the native resolution of the video, the sender SHOULD apply upscaling in order to provide that resolution.  The sender SHOULD NOT apply upscaling in any other cases. If there is no appropriate scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </del> <ins> satisfy the criteria. If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may not be appropriate in all cases.  To address this concern, the application can set an upscaling policy for each sent track.  For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution. Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD NOT upscale in other cases, even if the policy permits it. If there is no appropriate and permitted scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </ins> In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.

Discussion:
LGTM with the change indicated above.
I rearranged the text a bit to make the policy concept more clear. PTAL.
LGTM
LGTM
For example, some decoders may have min limits, expressed in imageattr. By default, upscaling can be used for this, but there should be some control to turn this off (e.g. don't want to send "HD" video that is just upscaled to HD)
Thoughts on if default should be upscale is allowed or not allowed ?
Generally it seems like a bad practice so I would default to not.
Change:
number of acknowledgments allows connection throughput to scale much further. <del> As discussed in implementation however, there are undesirable </del> <ins> As discussed in implementation however, there can be undesirable </ins> consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.  A sender's constraints on the acknowledgement frequency need to be taken into

Discussion:
“As discussed in Section 9 however, there are undesirable consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.“ This is a harsh statement. I don’t think it is true for smaller changes. There is much experience of using TCP where stretch ACKs cover more than two packets. This is a matter of scale. For instance: I’m confident that stretched TCP ACKs covering 4 segments (maybe more ... I’d love to say up to IW) would not break TCP CC, so I don’t see why the editors want to suggest it could break QUIC CC! This really does need a less obfuscated explanation.
I'd be happy to reword this to "there can be undesirable consequences ...", but were you looking for a larger change?
Thanks - yes, /can be/ would seem fair, since they are enumerated later.
This seems an improvement, thanks.
Change:
instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. <ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not silently violate the application's expectation of confidentiality or integrity of its payload data. </ins> 3. QUIC provides for 0-RTT connection establishment.  Though the same

Discussion:
Applicability section 2 says: I'm not sure how practical this advice is. Requiring a fallback to TLS 1.3 specifically seems problematic due to the diversity of HTTP versions and TLS versions that are deployed today. (NB: I agree with a general raising of the bar for security, but I don't think this document is the place to state it) We can assume that any HTTP version might learn about HTTP/3 via Alt-Svc or HTTPSVC. This could for example be HTTP/1.1 over TCP port 80. Such a client could fallback to the version it learned about QUIC from, and nothing bad would happen.
This wasn't meant to enforce any restriction. The assumption was simply that if you have implemented QUIC, you might have probably also implemented TLS1.3... however, I guess we can just remove the "1.3" here and only say "TLS over TCP". Okay?
One could argue it should require TLS 1.3, since otherwise there's an easy security downgrade, but I'm not sure that's something we could require.
IMO we need to accommodate disparate support across versions. To give an example, a CDN operator may have QUIC and HTTP endpoints that are configured differently according to customer configuration. With QUIC v1 it is safe to assume only TLS 1.3 so a CDN might not provide configuration for TLS version. However, other HTTP versions could theoretically be configured only to support a maximum of TLS 1.2. Since plaintext HTTP and TLS 1.2 are not prohibited for use on the internet, it seems odd to levy a requirement that prevents them being used in one specific chain of interactions. Mirja's suggestion to say "TLS over TCP" is better but would still not address the plaintext HTTP case. A user agent might see URL, connect to port 80, and get Alt-Svc'd to HTTP/3. If the something goes wrong and TLS is not permitted, then all connectivity might be broken forever.
In the same section later we say I hope that addresses your point about security downgrade, NAME ?
It might be worth saying "likely to impose a degradation on performance and can degrade security;"?
I created a PR and also changed the order of sentences a bit to make the it more clear. NAME is there anything else you think we need to say here?
Change:
Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is <del> authorized. </del> <ins> authorized.  Trusted endpoint authorization is described in the (add ref to new signaling draft here). </ins> A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects of denial of service attacks (refer to attacks), etc, to a level <del> equal to or better than traditional conferencing (i.e. pre-PERC) </del> <ins> equal to or better than traditional conferencing (i.e. non-PERC) </ins> deployments. A Media Distributor or associated conferencing infrastructure may

Discussion:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.
Change:
4.2.8.2. Clients are permitted to "stream" 0-RTT data until they receive the <del> server's Finished, only then sending the "end_of_early_data" alert. In order to avoid deadlock, when accepting "early_data", servers MUST </del> <ins> server's Finished, only then sending the EndOfEarlyData message.  In order to avoid deadlock, when accepting "early_data", servers MUST </ins> process the client's ClientHello and then immediately send the <del> ServerHello, rather than waiting for the client's "end_of_early_data" alert. </del> <ins> ServerHello, rather than waiting for the client's EndOfEarlyData message. </ins> 4.2.8.3.

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
This design does not provide post-compromise security for responses. <del> A only needs to retain keying material that might be used compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a </del> <ins> A only needs to retain keying material that might be used to compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a </ins> compromise. A server retains a secret key that might be used to remove protection

Discussion:
From NAME First and only time KeyConfig appear in the text. Section 6.7: Missing "to" after "used" Section 6.7: Remove the first "affected" Section 7: Missing "to" before prevent, remove "of"
Change:
or split-tunnel. In this case, the client does not specify any scope in its request. <del> The server assigns the client an IPv4 address to the client (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </del> <ins> The server assigns the client an IPv4 address (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </ins> A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this

Discussion:
Edits collected while reading this draft. cc: NAME NAME
LGTM, thanks for this NAME !
Change:
"a=ice-lite" Note that when BUNDLE is used, any additional attributes that are <del> added MUST follow the advice in I-D.nandakumar-mmusic-sdp-mux- attributes on how those attributes interact with BUNDLE. </del> <ins> added MUST follow the advice in I-D.ietf-mmusic-sdp-mux-attributes on how those attributes interact with BUNDLE. </ins> 5.2.2.

Discussion:
Justin, what are you looking for me to do here?
? This is ancient.
it seems this was dealt with long ago. I have no idea why it says I assigned it to EKR and hour ago ?
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
From EMAIL: Question 1: Should this be interpreted literally, to mean "the next call, and only the next call to createOffer will generate new ICE credentials"? If so, there are various situations wherein one could encounter unexpected behavior. For example: Before createOffer is called, a remote offer is received that triggers an ICE restart. Should the next call to createOffer trigger another, superfluous ICE restart? createOffer is called twice, without setting the local description (and kicking off a new gathering phase). Should the second call generate new credentials, or only the first? I would propose a slight change, such as: "this will cause subsequent calls to createOffer to generate new ICE credentials, until a new gathering phase has started." This would more clearly represent the intent of the original rule, in my opinion. Question 2: The next paragraph states "Any changes to the ICE candidate policy also affect the next gathering phase, in similar fashion to the server changes described above." Does this mean that changes to the candidate policy will also cause an ICE restart, according to the same rules? I assume so, but figure it's worth asking.

On , any changes should set a needs-ice-restart bit, which is only cleared by setLD with new ICE credentials (although, possibly only by setLD + setRD, since the setLD could be rolled back) On , if the ICE policy is being made more restrictive, no ICE restart is needed. Obviously if less restrictive, then the needs-ice-restart bit will be set.
Both you proposed resolutions look good to me
Change:
In GNAP, key-bound access tokens are the default due to their higher security properties.  While bearer tokens can be used in GNAP, their <del> use should be limited onto to cases where the simplicity benefits outweigh the significant security downsides. </del> <ins> use should be limited to cases where the simplicity benefits outweigh the significant security downsides. </ins> 11.8.

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
Network slice I-D.ietf-teas-ietf-network-slices. <del> A service attachment point is identified by an interface name </del> <ins> A Service Attachment Point is identified by an interface name </ins> ("attachment-id"), an interface type ("type"), a status ("admin- <del> status", and "oper-status"), an encapsulation type ("encapsulation- type"), one or a list of service types ("sap-type") such as L3VPN or network slice, a description of the service(s) ("service- description"). </del> <ins> status" and "oper-status"), an encapsulation type ("encapsulation- type"), one or a list of service types ("sap-type"), a description of the service(s) ("service-description"). "attachment-id" may include a reference to a physical or a logical interface.  For example, an "attachment-id" may be the interface identifier of a VPN network access used in Section 7.6 of I-D.ietf- opsawg-l3sm-l3nm. </ins> 5. The SAP network model can be seen as an inventory data associated <del> with service attachment points.  The model maintains an inventory of nodes contained in a network based on [RFC8345]. </del> <ins> with SAPs.  The model maintains an inventory of nodes contained in a network based on RFC8345. </ins> fig5 depicts the relationship of the SAP network model to other models.  The SAP network model augments from the Network model

Discussion:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:
Change:
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets <del> transports.  It also formally updates RFC7641 for use with these </del> <ins> transports.  It also formally updates RFC 7641 for use with these </ins> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. 1. The RFC7252 was designed for Internet of Things (IoT) deployments, <del> assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. </del> <ins> assuming that UDP RFC0768 or Datagram Transport Layer Security (DTLS) RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. </ins> Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received

Discussion:
Updates for acronyms Minor style change to Abstract
Please spell out acronyms at first use. I will correct the BERT case and also review URL for other potential cases.
Change:
options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. <del> For each candidate that has been gathered during the most recent gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. For the current default candidate, a "c=" line, as specified in RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. </del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature.

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
None <del> 12.  References </del> <ins> 10.  References </ins> <del> 12.1.  URIs </del> <ins> 10.1.  URIs </ins> [1] mailto:webtransport@ietf.org

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

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
3.1.1. <del> A client which supports this specification SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </del> <ins> A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello.  The body of the extension consists of a SignatureSchemeList: If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send

Discussion:
Hearing no objections on the list, merging this in. NAME can you please spin a new version for WGLC?
Allow the client to send a list of signature schemes that are supported in a delegated credential handshake.
Fixed by .