jiebi/CodeConvo huggingface dataset:
Code change:
Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the <del> network without risking connection failure.  Further, the reply from </del> <ins> network without causing connection failure.  Further, the reply from </ins> the server cannot be observed, so observers on the network cannot know which parameters are actually in use.

Related discussion:
text: This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.
Code change:
The endpoint accepting incoming QUIC connections. <ins> When used without qualification, the tuple of IP version, IP address, UDP protocol, and UDP port number that represents one end of a network path. </ins> An opaque identifier that is used to identify a QUIC connection at an endpoint.  Each endpoint sets a value for its peer to include in packets sent towards the endpoint.

Related discussion:
text: Some definitional work for terms that were poorly used. Note that "host" in the remaining uses is strictly interpreted in the RFC 1122 sense, so I left those alone. I considered sorting the terms section differently, and might still alphabetize that, but this isn't problematic just yet.
The word "host" is undefined. If it is equal to "endpoint", it should be replaced. Otherwise, "host" should" be defined in Sec 1.2. The word "address" sometime means "IP address" and "a pair of IP address and port" in other cases. Sec 1.2 should define "address" as "a pair of IP address and port". And "IP" should be added in front of "address" which means "IP address".
fixed this.
Thank you!
Code change:
VPNs from residential users as they stopped commuting and switched to work-at-home. <ins> Again, it will be helpful for streaming operators to monitor traffic as described in measure-coll, watching for sudden changes in performance. </ins> 4. Streaming media latency refers to the "glass-to-glass" time duration,

Related discussion:
text: Fixed a few typos, otherwise ready to merge.
Merging on Ali's review.
From NAME (URL) (In Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely) Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past.
Code change:
VPNs from residential users as they stopped commuting and switched to work-at-home. <ins> Again, it will be helpful for streaming operators to monitor traffic as described in measure-coll, watching for sudden changes in performance. </ins> 4. Streaming media latency refers to the "glass-to-glass" time duration,

Related discussion:
text: Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond.
Code change:
VPNs from residential users as they stopped commuting and switched to work-at-home. <ins> Again, it will be helpful for streaming operators to monitor traffic as described in measure-coll, watching for sudden changes in performance. </ins> 4. Streaming media latency refers to the "glass-to-glass" time duration,

Related discussion:
text: For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022.
Code change:
VPNs from residential users as they stopped commuting and switched to work-at-home. <ins> Again, it will be helpful for streaming operators to monitor traffic as described in measure-coll, watching for sudden changes in performance. </ins> 4. Streaming media latency refers to the "glass-to-glass" time duration,

Related discussion:
text: Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section
Code change:
1. <del> QUIC RFC9000 has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </del> <ins> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </ins> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to

Related discussion:
text: This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.
Code change:
4.1. <del> (To the editor: check this repository URL after the draft is adopted. The working group may create its own repository) </del> <ins> This document is in the Github repository at: </ins> <del> This document is in the Github repository at https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are welcome to open issues and send pull requests for this document. </del> <ins> https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons Readers are welcome to open issues and send pull requests for this document. </ins> Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). <ins> Join: https://www.ietf.org/mailman/listinfo/mops Search: https://mailarchive.ietf.org/arch/browse/mops/ </ins> 4.2. Presentations: IETF 105 BOF: https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s <del> IETF 106 Mops meeting: https://www.youtube.com/ </del> <ins> IETF 106 meeting: https://www.youtube.com/ </ins> watch?v=4_k340xT2jM&t=7m23s <del> List archive search for doc mentions: https://mailarchive.ietf.org/arch/browse/mops/?q=draft-ietf-mops- streaming-opcons </del> 5. This document requires no actions from IANA.

Related discussion:
text: I actually used the URL in the draft to clone a copy, so I think this is good to go.
Code change:
4.5.2. If the Record has no Unit, the Base Unit is used as the Unit.  Having <del> no Unit and no Base Unit is allowed. </del> <ins> no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context. </ins> 4.5.3.

Related discussion:
text: As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM
Code change:
defined in Section 6 of TLS13. A TLS alert is converted into a QUIC connection error.  The <del> AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </del> <ins> AlertDescription value is added to 0x0100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal

Related discussion:
text: One possible resolution to ; all literals are zero-padded to full bytes.
IANA made the following observation while creating the H3 registries: While the IANA copy of the registry uses two digits throughout, the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros. Is it worth updating our hex literals to use full bytes (, , etc.) or synchonizing on some other format? We probably shouldn't synchronize on trimming, since IANA has already skewed the other way.
NAME did fix this or do we need to inform IANA also?
We should probably shoot IANA an e-mail to update the registries with leading zeroes where they hadn't already assumed them.
I'll let you do that. The only registries that are affected are in HTTP/3 and QPACK.
Fixed both in the registry and the documents.
Yeah, this is easy to understand. The tables must have been annoying.
Code change:
private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to

Related discussion:
text: Just some nits.
The public key name and type have been changed in , as NAME suggested on the mailing list.
NAME beat me to it!
oh looks like the travis build is failing for some reason
NAME I have no idea why pushing that worked ...
awesomesauce. it's probably some temporary failure while trying to fetch the new references or something
Code change:
The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <del> "valid" or "deactivated" </del> <ins> The status of this registration.  Possible values are: "valid", "deactivated", and "revoked". "deactivated" should be used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. </ins> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may

Related discussion:
text: what's the difference between "deactivated" and "revoked"?
Deactivated is done by the user; revoked is done by an administrator.
OK, so we need to either say that or use clearer terms :) I talked with NAME offline, and I think he's going to propose something.
Code change:
The DTLSCiphertext structure omits the superfluous version number and type fields. <del> DTLS adds an explicit epoch and sequence number to the TLS record header.  This sequence number allows the recipient to correctly verify the DTLS MAC.  However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure have been reduced. </del> <ins> DTLS adds an epoch and sequence number to the TLS record header. This sequence number allows the recipient to correctly verify the DTLS MAC.  However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure have been reduced. </ins> The DTLSCiphertext structure has a variable length header.

Related discussion:
text: The draft states in three places that DTLS use explicit sequence numbers, while this was true for DTLS 1.2, the sequence number in the DTLSCipherstructure is a mixture of implicit and explict. Maybe "Partly Explicit"?
Please provide me with a PR to add your name to acknowledgements.
Hi, I don’t know what PR is an abbreviation for but I guess it is not clear from my username who I am. I should probably update it, I did not intend to be anonymous :) John Mattsson, Ericsson, EMAIL
Code change:
clearer. Session Information ("i="), URI ("u="), Email Address ("e="), <del> Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </del> <ins> Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </ins> Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.

Related discussion:
text: Originally raised by Magnus: Section 5.2.1: o Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. Considering that b=CT is not useless, I am a bit surprised to see b= on this list. Yes, b=CT: is only useful is one like to provide a upper total bandwidth limitation. So, maybe some discussion of the possible choice?
This is just a mistake in 5.2.1 - we cover how to deal with it later in section 5. Prob need to remove the mention of b= here.
Code change:
who have not implemented WebRTC at all, WebRTC implementations need to be more careful. <del> Consider the case of a call center which accepts calls via RTCWeb. </del> <ins> Consider the case of a call center which accepts calls via WebRTC. </ins> An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center.  Note that this requires user consent in many cases but because the data channel

Related discussion:
text: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.
Code change:
messages received. The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction <del> Identifier (Tid), and SHALL be unique for each Base Key. The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </del> <ins> Identifier (Tid), and SHALL be unique for each Master Secret.  The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </ins> 3.2.

Related discussion:
text: , and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02
Code change:
6.3.2.1. This sub-tree defines the L2VPN service type, according to the <del> several signalling options to exchange membership information between </del> <ins> several signaling options to exchange membership information between </ins> PEs of an L2VPN.  The following signaling options are supported: <del> Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. </del> <ins> The service is a Multipoint VPLSs that use a BGP control plane as described in RFC4761 and RFC6624.  For this L2VPN service, the model allows configuring the Route Distinguisher, the Route Targets, the PWE encapsulation type and the MTU configurations to allow MTU mismatch. The service is a Multipoint VPLSs that use also a BGP control plane but also includes the additional features and related parameters RFC7432 and RFC7209.  The model allows the configuration of the EVPN service interface type, the local and remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for handling MAC addresses and the Ethernet Segment Identifier (ESI) information. </ins> <del> Refers to LDP-signaled pseudowires RFC6074. </del> <ins> A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires RFC6074.  The model allows configuring the T-LDP PWE type, MTU mismatch and the list of AC and PW bindings. </ins> <del> Refers to L2TP-signaled pseudowires RFC6074. </del> <ins> The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074. The model allows configuring TBC. </ins> 6.3.2.2.

Related discussion:
text: Adding a description to signaling options to improve readability. I have pending to update L2TP after the other issue is solved URL
Thanks, Victor. Does the text reflect the latest version of signaling/discovery split?
leaf l2tp-type { type identityref { base t-ldp-pwe-type; } description "T-LDP PWE type."; }
The type should be taken from this registry: URL
A new IANA-maintained module is created to fix this issue.