jiebi/CodeConvo huggingface dataset:
Change:
Note that there can be more than one Service Discovery Instruction for the same name if the SRP requestor is advertising more than one <del> service of the same type, or is changing the target of a PTR RR.  For each such PTR RR add or remove, the above constraints must be met. </del> <ins> service of the same type, or is changing the target of a PTR RR. This is also true for SRP subtypes (RFC6763).  For each such PTR RR add or remove, the above constraints must be met. </ins> 2.3.1.2.

Discussion:
This update removes the constraint in the section titled "Host Description Instruction" that the Host Description instruction must be pointed to by at least one Service Description instruction. It also removes some duplicate constraints from the section titled "Valid SRP Update requirements" and moves the mention of subtypes to the "Service Discovery Instruction" section.
Change:
software tools can understand and use. The enterprise has a means of identifying enterprise endpoints <del> although assertions about some details of this capability are made. </del> <ins> through the execution of Target Endpoint Discovery Tasks although assertions about some details of this capability are made. </ins> The enterprise has a means of extracting relevant information about enterprise endpoints in a form that is compatible with the

Discussion:
We should examine the vulnerability assessment process outlined in the draft and determine the alignment with SACM tasks and update as necessary.
URL
Addressed in URL During yesterday's virtual interim meeting, we discussed various open issues with respect to the Vulnerability Assessment Scenario [1] as a result of feedback that we received on the draft which you can see here [2][3]. The slide's from the meeting can be found here [4]. One issue that we didn't have a chance to discuss because we ran out of time was whether or not an endpoint management capability has the ability to push supplemental endpoint information to the vulnerability assessment capability. This question came out of a review of the following text from the Vulnerability Assessment Scenario (specifically the last sentence). "In many cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected by the Endpoint Management Capability and available in a Repository. However, in other cases, the necessary endpoint information will not be readily available in a Repository and a targeted collection will be necessary. Of course, an implementation of an endpoint management capability may prefer to enable operators to perform targeted collection under certain circumstances, even when sufficient information can be provided by the endpoint management capability (e.g. there may be freshness requirements for information). Targeted collection of endpoint information for the purpose of vulnerability assessment does not necessarily need to be a pull by the vulnerability assessment capability. Under certain deployment scenarios, once the necessary detection information is known, the information beyond that which is available in the endpoint management capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes." Our main question is whether or not pushing information from the endpoint management capability to the vulnerability assessment capability is actually possible because it would not necessarily know what information it needs to push prior to the server requesting it (in which case it is probably considered a pull)? Is there a situation where the endpoint would know, in advance, what additional information is needed for an assessment without a server requesting it? If you have any thoughts on this issue, please provide feedback by May 31st. We are planning to have an updated version of the scenario for June 8th. Thanks, Danny [1] URL [2] URL [3] URL [4] URL (looks like the slides are not available just yet, but, I suspect they should be soon)
Change:
the negotiated session descriptions by following the steps mentioned for the "have-local-offer" state above. <del> In addition, for each non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current remote description, if any: </del> <ins> In addition, for each existing, non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current local or remote description, as appropriate: </ins> The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST <del> only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated transceiver.  Note that non-JSEP endpoints are not subject to these restrictions, and might offer media formats that were not present in the most recent answer, as specified in RFC3264, Section 8.  Therefore, JSEP implementations MUST be prepared to receive such offers. </del> <ins> only include media formats which have not been excluded by the codec preferences of the associated transceiver, and MUST include all currently available formats.  Media formats that were previously offered but are no longer available (e.g., a shared hardware codec) MAY be excluded. </ins> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in <del> the same order as in the current local description. </del> <ins> the same order as in the most recent answer.  Any media formats that were not present in the most recent answer MUST be added after all existing formats. </ins> The RTP header extensions MUST only include those that are present in the most recent answer. <del> The RTCP feedback extensions MUST only include those that are present in the most recent answer. </del> <ins> The RTCP feedback mechanisms MUST only include those that are present in the most recent answer, except for the case of format- specific mechanisms that are referencing a newly-added media format. </ins> The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line.

Discussion:
any guess on what happened to these that caused them to not go in ?
They were somehow targeted to a branch other than master, and that branch was never merged
LGTM but you have a conflict
Change:
3.3. <del> Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling RFC3449.  Distinguishing ACK packets is possible in TCP, but is not supported by QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying packets based on packet size are likely to fail, and are not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </del> <ins> Some deployed in-network functions distinguish packets that carry only acknowledgment (ACK-only) information from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling RFC3449.  Distinguishing ACK packets is possible in TCP, but is not supported by QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible. Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying packets based on packet size are likely to fail, and are not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </ins> 3.4.

Discussion:
URL, what is a pure-acknowledgment (ACK) packet?
Change:
numbers of load-balancing tiers, as the maximum server ID space is quite large. <ins> 7.2. Some deployments may transparently move a connection from one server to another.  The means of transferring connection state between servers is out of scope of this document. To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, and retire CIDs associated with the new server using the "Retire Prior To" field in that frame. Alternately, if the old server is going offline, the load balancer could simply map its server ID to the new server's address. </ins> 8. QUIC-LB is intended to prevent linkability.  Attacks would therefore

Discussion:
Intended to
Some text on how a server cluster might support moving of connections from one server instance to another would be useful. The current design might permit portability under certain conditions, but there are things that might need to be considered, such as the way in stateless resets are generated.
Are you referring to load balancing already existing connections to a new server? Are you envisioning the first server issuing new CIDs (that point to the new server) and setting Retire Prior To to retire the old CIDs so that future traffic redirect to the new server? How do you imagine the rest of the connection state would get moved?
This applies to cases where clusters are rebalanced, where instances go down and others are expected to pick up the slack, and all similar cases. In some cases this requires an unspecified mechanism for transferring state between instances. In others, the instance might remain constant but the identifiers used might need to rotate. This is likely addressed by using Retire Prior To as you say. Text on that would help.
Good idea, it wouldn't hurt to have a short non-normative section on this.
Seems fine.
Change:
Each SFrame session uses a single ciphersuite that specifies the following primitives: <del> o A hash function used for key derivation and hashing signature inputs </del> <ins> o A hash function used for key derivation </ins> o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag <del> o [Optional] A signature algorithm </del> This document defines the following ciphersuites: In the "AES" suites, the length of the authentication tag is

Discussion:
The signature mechanism was removed from SFrame some time ago. This PR removes a few remaining references to it.
Seems good but needs rebasing
NAME NAME I think we are ok to merge this PR?
Change:
and response to the authz-info endpoint between client and RS.  The client generates a nonce N1, and posts it together with the token that includes the materials (e.g., OSCORE parameters) received from <del> the AS to the RS.  The RS then generates a nonce N2, and use </del> <ins> the AS to the RS.  The RS then generates a nonce N2, and uses </ins> Section 3.2 of RFC8613 to derive a security context based on a shared master secret and the two nonces, established between client and server.  The nonces are encoded as CBOR bstr if CBOR is used, and as

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.
Change:
a solution to this problem.  However, hiding information about the change of the IP address or port conceals important and security- relevant information from QUIC endpoints and as such would facilitate <del> amplification attacks (see Section 9 of QUIC-TRANSPORT).  A NAT </del> <ins> amplification attacks (see Section 8 of QUIC-TRANSPORT).  A NAT </ins> function that hides peer address changes prevents the other end from detecting and mitigating attacks as the endpoint cannot verify connectivity to the new address using QUIC PATH_CHALLENGE and

Discussion:
instead of sec 9 (migration)
URL, is this referring to the right section? if yes then can it be made specific to a particular subsection? I noted that RFC9000 describes the potential amplification attack in section 21.3
Yes this should probably be section 8; 21.3 is not relevant here.
Change:
A sender bundles one or more frames in a QUIC packet; see frames. A sender can minimize per-packet bandwidth and computational costs by <del> bundling as many frames as possible within a QUIC packet.  A sender MAY wait for a short period of time to bundle multiple frames before </del> <ins> including as many frames as possible in each QUIC packet.  A sender MAY wait for a short period of time to collect multiple frames before </ins> sending a packet that is not maximally packed, to avoid sending out large numbers of small packets.  An implementation MAY use knowledge about application sending behavior or heuristics to determine whether

Discussion:
We didn't really need to use a new "term" for the concept of including multiple frames in a packet. The use of "bundle" implied more than what was really happening. Using plain words is probably better.
What does “bundling” refer to? I think I might now understand coalescing, but I don’t understand if bundling is subtly different?
Several instances I see in the draft refer to the situation where an endpoint is required to send a packet containing certain frames. The endpoint might opportunistically add other frames, not mandated to be sent, as long as it's doing the work of generating and sending a packet anyway. These opportunistically added frames are "bundled" with the mandatory frames. More generally, the term refers to selecting a collection of frames waiting to be sent when generating an outgoing packet.
(Versus coalescing, which is putting more than one packet in a single UDP datagram.)
tbh, I think the text reads a lot better with bundling.Thanks! Clearer is better.
Change:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-13 </del> <ins> draft-ietf-rtcweb-transports-14 </ins> Abstract

Discussion:
Notes that there's no way to mark a stream as non-interactive.
From discussion with DSCP folks:
after
Discussion people: Cc: EMAIL; EMAIL; EMAIL; EMAIL; Black, David
I chose to integrate this minus the G.1010 reference, since I did not know how to get that reference in using XML2RFC markup, and the reference to 4594 already covers it.
Fixed in (version -14)
Change:
Version Negotiation packets on that connection. Both endpoints MUST parse their peer's Version Information during the <del> handshake.  If the Version Information was missing or if parsing it failed (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "TRANSPORT_PARAMETER_ERROR". </del> <ins> handshake.  If parsing the Version Information failed (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "TRANSPORT_PARAMETER_ERROR". If the Version Information was missing, the endpoints MAY complete the handshake if they have reason to believe the peer might not support this extension.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR". </ins> If a client has reacted to a Version Negotiation packet, it MUST validate that the server's "Other Versions" field does not contain

Discussion:
Section 5 describes Version Downgrade Prevention. If a client receives a VN packet and selects a new attempted version, it will format the "compatible VN" extension and document in it the previously attempted version and the VN parameters. The server who understands the extension will then verify that the VN was not a downgrade attack. This supposes that the server supports the extension. If it does not, the server will ignore the parameter, and will not verify anything. It also will not include that parameter in its parameter set. What should the client do in that scenario? Should it just close the connection with versionnegotiation error?
Change:
values associated with the true server name in the ClientHelloOuter. It MAY send such values in the ClientHelloInner. <ins> A client may also use different preferences in different contexts. For example, it may send a different ALPN lists to different servers or in different application contexts.  A client that treats this context as sensitive SHOULD NOT send context-specific values in ClientHelloOuter. </ins> Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in <del> ClientHelloOuter and compressed as described in outer-extensions. </del> <ins> ClientHelloOuter.  If they match the corresponding ClientHelloInner, they MAY be compressed as described in outer-extensions.  However, note the payload length reveals information about which extensions are compressed, so inner extensions which only sometimes match the corresponding outer extension SHOULD NOT be compressed. [[OPEN ISSUE: In addition to the fuzzy leak from the length, there is an active attack to probe compressed extensions.  See issue #323.  We should either document this attack, or bind ClientHelloOuter.]] Clients MAY include additional extensions in ClientHelloOuter to avoid signaling unusual behavior to passive observers, provided the choice of value and value itself are not sensitive.  See do-not- stick-out. </ins> 10.6.

Discussion:
I noticed there's an OPEN ISSUE to add ClientHelloOuter guidance, but there's already a section for it. Link to it and flesh it out a little more. Sadly, in doing so, I've traded one OPEN ISSUE for another OPEN ISSUE, but hopefully that'll be closed shortly.
Change:
the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: <del> 9.2. </del> <ins> 10.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 9.3. </del> <ins> 10.3. </ins> <del> This document establishes a registry for HTTP/3 frame type codes. </del> <ins> This document establishes a registry for HTTP/3 capsule type codes. </ins> The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields:

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks
Change:
to augment their capabilities in order to fulfill their application tasks.  This is hard and partly impossible to achieve with cloud services for systems such as vehicles, drones, or oil rigs that have <del> intermittent network connectivity. </del> <ins> intermittent network connectivity.  Example of related challenges include support for IoT device and edge computing node mobility, as well as software instance migration. </ins> 4.4.

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:
4.2.3. <del> The PRIORITY (type=0x02) frame specifies the client-advised priority </del> <ins> The PRIORITY (type=0x2) frame specifies the client-advised priority </ins> of a request, server push or placeholder. A PRIORITY frame identifies an element to prioritize, and an element

Discussion:
Simply making this consistent through the document by doing the minimal change and removing leading 0s. Happy to add them if we prefer.
Works for me.