jiebi/TextFlow huggingface dataset:
Original text:
correctly enabled.  The requested URL is the root path of the TIPS view, appended with "push", as shown below. <del> The server returns an JSON object with content type "application/ alto-tipsparams+json".  The response MUST include only one field "server-push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </del>  8.1.3.

Reviewer comments:
Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.

Revised text:
correctly enabled.  The requested URL is the root path of the TIPS view, appended with "push", as shown below.  <ins> The server returns a JSON object with content type "application/alto- tipsparams+json".  The response MUST include only one field "server- push".  If the server push is enabled, the value of the "server-push" field MUST be the JSONBool value "true" (without the quote marks), and otherwise JSONBool value "false" (without the quote marks). </ins> 8.1.3.
Original text:
is communicated using PACI Extensions defined in [RFC7798] Section 4.4.4.2. A WebRTC implementation that has negotiated use of RTP header extensions containing TSCI information (such as the Dependency Descriptor [DD]) SHOULD <del> NOT send TSCI information within the PACI, and where TSCI information is being received in RTP header extensions MUST ignore TSCI information contained in the PACI. </del>  Implementations of the H.265 codec have utilized a wide variety of optional parameters.  To improve interoperability, the following

Reviewer comments:
Fix for
NAME PTAL
NAME PTAL
(moved to issue)
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.

Revised text:
is communicated using PACI Extensions defined in [RFC7798] Section 4.4.4.2. A WebRTC implementation that has negotiated use of RTP header extensions containing TSCI information (such as the Dependency Descriptor [DD]) SHOULD  <ins> NOT send TSCI information within the PACI.  If TSCI information is being received in an RTP header extension, implementations MUST ignore TSCI information contained in the PACI. </ins> Implementations of the H.265 codec have utilized a wide variety of optional parameters.  To improve interoperability, the following
Original text:
tx-mode: Implementations SHOULD NOT include this parameter within SDP. If no tx-mode parameter is present, a value of "SRST" MUST be inferred. <del> Support for the "MRST" and "MRMT" modes is OPTIONAL; implementations that do not support the "MRST" or "MRMT" modes MUST NOT include these modes in the tx-mode parameter. </del>  sprop-sps, sprop-pps, sprop-vps, sprop-sei: H.265 allows sequence and picture information to be sent both in-band and out-of-band.  WebRTC implementations

Reviewer comments:
Add discussion of the tx-mode SDP parameter. Fix for Rebase of
NAME PTAL
I think we need a different approach. We want to say that support for "SRST" mode is mandatory If no tx-mode parameter is present, a value of "SRST" MUST be inferred. It is up to the offering implementation whether to include SRST or omit it. implementations that do not implement the other modes should not negotiate a codec with that mode
NAME Updated the PR to include your suggestions.
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.

Revised text:
tx-mode: Implementations SHOULD NOT include this parameter within SDP. If no tx-mode parameter is present, a value of "SRST" MUST be inferred.  <ins> Implementations MUST support "SRST"; support for "MRST" and "MRMT" is OPTIONAL. Implementations that do not support "MRST" or "MRMT" MUST NOT include these tx-mode values in SDP. </ins> sprop-sps, sprop-pps, sprop-vps, sprop-sei: H.265 allows sequence and picture information to be sent both in-band and out-of-band.  WebRTC implementations
Original text:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming <del> draft-ietf-avtcore-rtp-j2k-scl-02 </del>  Abstract

Reviewer comments:
In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)

Revised text:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming  <ins> draft-ietf-avtcore-rtp-j2k-scl-03 </ins> Abstract
Original text:
11. This memo requests that IANA registers the content type specified at <del> sec-media-type.  The media type is also requested to be added to the IANA registry for RTP Payload Format MIME types [1]. </del>  12.

Reviewer comments:
In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)

Revised text:
11. This memo requests that IANA registers the content type specified at  <ins> sec-media-type. </ins> 12.
Original text:
Security considerations related to the JPEG 2000 codestream contained in the payload are discussed at RFC3745. <del> 13.  References 13.1.  URIs [1] http://www.iana.org/assignments/rtp-parameters </del>

Reviewer comments:
In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)

Revised text:
Security considerations related to the JPEG 2000 codestream contained in the payload are discussed at RFC3745.
Original text:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming <del> draft-ietf-avtcore-rtp-j2k-scl-03 </del>  Abstract

Reviewer comments:
specifies the The low-order bits should be specifies the low-order bits Subbands to Sub-bands signalling to signaling
URL

Revised text:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming  <ins> draft-ietf-avtcore-rtp-j2k-scl-04 </ins> Abstract
Original text:
This document defines state variables and constants for the BBR algorithm. <del> The variables starting with C, P, or rs not defined below are defined in delivery-rate-samples, "Delivery Rate Samples". </del>  2.1.

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
This document defines state variables and constants for the BBR algorithm.  <ins> Variables for connection state (C), per-packet state (P), or per-ACK rate sample (rs) that are not defined below are defined in delivery- rate-samples, "Delivery Rate Samples". </ins> 2.1.
Original text:
bottleneck link in one round-trip or less.  As noted in BBRDrainPacingGain, any value at or below 1 / BBRStartupCwndGain = 1 / 2 = 0.5 will theoretically achieve this.  BBR uses the value 0.35, <del> which has been shown to offer good performance on YouTube, when compared with other alternatives. </del>  2.6.

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
bottleneck link in one round-trip or less.  As noted in BBRDrainPacingGain, any value at or below 1 / BBRStartupCwndGain = 1 / 2 = 0.5 will theoretically achieve this.  BBR uses the value 0.35,  <ins> which has been shown to offer good performance when compared with other alternatives. </ins> 2.6.
Original text:
all three tactics, to measure the network path and try to optimize its operating point. <del> BBR's state machine uses two control mechanisms.  Primarily, it uses the pacing_gain (see the "Pacing Rate" section), which controls how fast packets are sent relative to BBR.bw.  A pacing_gain > 1 decreases inter-packet time and increases inflight.  A pacing_gain < 1 has the opposite effect, increasing inter-packet time and while aiming to decrease inflight.  Second, if the state machine needs to quickly reduce inflight to a particular absolute value, it uses the cwnd. </del>  4.2.

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
all three tactics, to measure the network path and try to optimize its operating point.  <ins> BBR's state machine uses two control mechanisms: the pacing_gain and the cwnd.  Primarily, it uses the pacing_gain (see the "Pacing Rate" section), which controls how fast packets are sent relative to BBR.bw.  A pacing_gain > 1 decreases inter-packet time and increases inflight.  A pacing_gain < 1 has the opposite effect, increasing inter-packet time and while aiming to decrease inflight.  The cwnd is sufficiently larger than the BDP to allow the higher pacing gain to accumulate more packets in flight.  Only if the state machine needs to quickly reduce inflight to a particular absolute value, it uses the cwnd. </ins> 4.2.
Original text:
utilized the per-flow available bandwidth, and sets both BBR.full_bw_now and BBR.full_bw_reached to true. <del> Upon starting a full pipe detection process, the following initialization runs: </del>  While running the full pipe detection process, upon an ACK that acknowledges new data, and when the delivery rate sample is not application-limited (see delivery-rate-samples), BBR runs the "full pipe" estimator: <del> BBR waits three rounds to have solid evidence that the sender is not detecting a delivery-rate plateau that was temporarily imposed by the receive window.  Allowing three rounds provides time for the receiver's receive-window auto-tuning to open up the receive window and for the BBR sender to realize that BBR.max_bw should be higher: in the first round the receive-window auto-tuning algorithm grows the receive window; in the second round the sender fills the higher receive window; in the third round the sender gets higher delivery- rate samples.  This three-round threshold was validated by YouTube experimental data. </del>  4.3.1.3.

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
utilized the per-flow available bandwidth, and sets both BBR.full_bw_now and BBR.full_bw_reached to true.  <ins> Upon starting a full pipe detection process (either on startup or when probing for an increase in bandwidth), the following steps are taken: </ins> While running the full pipe detection process, upon an ACK that acknowledges new data, and when the delivery rate sample is not application-limited (see delivery-rate-samples), BBR runs the "full pipe" estimator:  <ins> BBR waits three packet-timed round trips to have reasonable evidence that the sender is not detecting a delivery-rate plateau that was temporarily imposed by congestion or receive-window auto-tuning. This three-round threshold was validated by experimental data to allow the receiver the chance to grow its receive window. </ins> 4.3.1.3.
Original text:
Startup by switching to a pacing_gain well below 1.0, until any estimated queue has been drained.  It uses a pacing_gain of BBRDrainPacingGain = 0.35, chosen via analysis BBRDrainPacingGain and <del> experimentation (on YouTube) to try to drain the queue in less than one round-trip: </del>  In Drain, when the amount of data in flight is less than or equal to the estimated BDP, meaning BBR estimates that the queue at the

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
Startup by switching to a pacing_gain well below 1.0, until any estimated queue has been drained.  It uses a pacing_gain of BBRDrainPacingGain = 0.35, chosen via analysis BBRDrainPacingGain and  <ins> experimentation to try to drain the queue in less than one round- trip: </ins> In Drain, when the amount of data in flight is less than or equal to the estimated BDP, meaning BBR estimates that the queue at the
Original text:
corresponding to that ACK, and generating a delivery rate sample at later a time (upon the arrival of the next ACK).  This can underestimate the delivery rate due the artificially inflated <del> "rs.interval".  As with any effect that can cause underestimation, it is RECOMMENDED that applications or congestion control algorithms using the output of this algorithm apply appropriate filtering to mitigate the impact of this effect. </del>  4.5.2.4.3.

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
corresponding to that ACK, and generating a delivery rate sample at later a time (upon the arrival of the next ACK).  This can underestimate the delivery rate due the artificially inflated  <ins> "rs.interval".  The impact of this effect is mitigated using the BBR.max_bw filter. </ins> 4.5.2.4.3.
Original text:
ends of the connections do not accept SACK), then this algorithm can be extended to estimate approximate delivery rates using duplicate ACKs (much like Reno and RFC5681 estimates that each duplicate ACK <del> indicates that a data packet has been delivered).  The details of this extension will be described in a future version of this draft. </del>  4.5.3.

Reviewer comments:
Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.

Revised text:
ends of the connections do not accept SACK), then this algorithm can be extended to estimate approximate delivery rates using duplicate ACKs (much like Reno and RFC5681 estimates that each duplicate ACK  <ins> indicates that a data packet has been delivered). </ins> 4.5.3.
Original text:
F3411-22a does not specify the time source, but GNSS is generally assumed, as latitude, longitude and geodetic altitude must be reported and most small UAS use GNSS for positioning and navigation. <del> F3586-22, to satisfy FAA_RID, specifies use of the US Government operated GPS (with its sub-microsecond accuracy but only 1.5 second precision) and tamper protection of the entire UAS RID subsystem. Thus, in messages sourced by the UA, timestamp accuracy and precision each can be assumed to be 1.5 seconds at worst.  GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in harvestbridforutm, but such better time sources cannot be assumed generally for purposes of security analysis. </del>  9.

Reviewer comments:
let's publish an I-D with this PR and the one about Personal Data, then I am approving the I-D for publication

Revised text:
F3411-22a does not specify the time source, but GNSS is generally assumed, as latitude, longitude and geodetic altitude must be reported and most small UAS use GNSS for positioning and navigation.  <ins> Note: For example, to satisfy FAA_RID, F3586-22 specifies tamper protection of the entire RID subsystem and use of the US Government operated GPS.  GPS has sub-microsecond accuracy and 1.5 second precision.  In this example, UA-sourced messages can be assumed to have timestamp accuracy and precision of 1.5 seconds at worst. GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in harvestbridforutm, but such better time sources cannot be assumed generally for purposes of security analysis. </ins> 9.
Original text:
1. <del> Digital Map provides a core multi-layer topology model and data and connects them to the other models and data.  This includes layers from physical topology to service topology. </del>  The Digital Map modelling defines the core topological entities (network, node, link, and interface) at each layer, their role in the

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
1.  <ins> Digital Map is a data model that provides a view of the operator's networks and services, including how it is connected to other models/ data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi- layered topology and appropriate mechanism to navigate amongs layers and correlate between them.  This includes layers from physical topology to service topology.  This model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). </ins> The Digital Map modelling defines the core topological entities (network, node, link, and interface) at each layer, their role in the
Original text:
2. <del> The document defines the following terms: </del>  <del> Network topology defines how physical or logical nodes, links and interfaces are related and arranged.  Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged.  There are at least 8 types of topologies: point to point, bus, ring, star, tree, mesh, hybrid and daisy chain. Topologies may be unidirectional or bidirectional (bus, some rings). </del>  <del> Defines a layer in the multilayer topology.  A multilayer topology models relationships between different layers of connectivity, where each layer represents a connectivity aspect of the network and service that needs to be configured, controlled and monitored. </del>  The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
2.  <ins> The document makes use of the following terms: Topology in this document refers to the network and service topology.  Network topology defines how physical or logical nodes, links and interfaces are related and arranged.  Service topology defines how service components (e.g., VPN instances, customer interfaces, and customer links) between customer sites are interrelated and arranged.  There are at least 8 types of topologies: point to point, bus, ring, star, tree, mesh, hybrid and daisy chain.  Topologies may be unidirectional or bidirectional (bus, some rings). </ins>  <ins> A multi-layered topology models relationships between different layers of topology, where each layer represents a connectivity aspect of the network and services that needs to be configured, controlled and monitored.  Each layer of topology has a separate lifecycle. </ins>  <ins> Represents topology at a single layer in the multi-layered topology. </ins> The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the