jiebi/CodeConvo huggingface dataset:
Code change:
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)

Related discussion:
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>
Code change:
specifies the The low-order bits should be specifies the low-order bits Subbands to Sub-bands signalling to signaling
URL

Related discussion:
text: RTP Payload Format for sub-codestream latency JPEG 2000 streaming <del> draft-ietf-avtcore-rtp-j2k-scl-03 </del> <ins> draft-ietf-avtcore-rtp-j2k-scl-04 </ins> Abstract
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> which has been shown to offer good performance when compared with other alternatives. </ins> 2.6.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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: <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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <ins> "rs.interval".  The impact of this effect is mitigated using the BBR.max_bw filter. </ins> 4.5.2.4.3.
Code change:
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.

Related discussion:
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> <ins> indicates that a data packet has been delivered). </ins> 4.5.3.
Code change:
let's publish an I-D with this PR and the one about Personal Data, then I am approving the I-D for publication

Related discussion:
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> <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.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
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> <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
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: 2. <del> The document defines the following terms: </del> <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> <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> <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> <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> <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
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: that can differ for different types of services and for different providers/solutions. <del> The top layer represents the application/flow view of </del> <ins> The top layer represents the application/flow view of service </ins> connectivity. <del> Basis for the Operator Network and Services Models that provides topological information of the network.  It provides the core multi-layer topology model/data and how to connect them to the other models/data. </del> <ins> The document defines the following terms: 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 model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). </ins> The set of principles, guidelines, and conventions to model the Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other <del> entities o. </del> <ins> entities. </ins> Defines the core topological entities, their role in the network, <del> core properties and relationships both inside each layer and between the layers. </del> <ins> core topological properties and relationships both inside each layer and between the layers. </ins> It is the basic topological model with the links to other models and connects them all: configuration, maintenance, assurance
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: nodes, links and termination points inside a network, relationships between instances belonging to different networks, links to functional data for the instances, including <del> configuration, health, symptoms.  :The data can be historical, real-time, or future data for 'what-if' scenarios. </del> <ins> configuration, health, symptoms. The data can be historical, real-time, or future data for 'what- if' scenarios. </ins> 3.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: operations use cases, but it is also a requirement for the Digital Twin. <ins> The following sections shows some example use case descriptions to initiate the discussion what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases, from the perspective of what is the value of the digital map for each use case and how the Digital Map API can be used.  This will also clarify if only read and if/when write interface is needed per use case. 3.1. The application will be able to retrieve physical topology from the controller via Digital Map API and from the response it will be able to retrieve physical inventory of individual devices and cables. The application may request either one or multiple layers of topology via the Digital Map API and and from the response it will be able to retrieve both physical and logical inventory. 3.2. 3.3. The application will be able to retrieve all services from the Digital Map API for selected network type.  The application will be able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it will be able to determine what logical resources are used by the service.  The supporting relations to the lowest layer will help application to determine what physical resources are used by the service. 3.4. The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example, the application will be able to select the resouce and by navigation the supporting relationship bottom-up come to the service and its nodes, tps and links. 3.5. The application will be able to retrieve topology layer and any network/node/tp/link instances from the controller via Digital Map API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. 3.6. The application will be able to retieve the topology at any layer from the controller via Digital Map API and from the response it will be able to navigate any retrieve any KPIs for selected topology entity. 3.7. 3.8. 3.9. 3.10. 3.11. </ins> 4. 4.1.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: that some of them are supported by default by RFC8345): Basic model with network, node, link, and interface entity types. This means that users of the Digital Map model must be able to understand topology model at any layer via these core concepts only, without having to go to the details of the specific
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: capability to retrieve the links to external data/models. Digital Map models and APIs must be common over different network <del> domains (campus, core, data center, etc.).  This means that clients of the Digital Map API must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains. </del> <ins> domains (campus, core, data center, etc.). This means that clients of the Digital Map API must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains. </ins> Digital Map must provide semantics for layered network topologies and for linking external models/data.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: 4.2. <del> The following are design requirements for modelling the Digital Map: </del> <ins> The following are design requirements for modelling the Digital Map. Theey are derived from the core requerements collected from the operators and although there is some duplication, these are focused on summarizing the requirements for the design of the model and API: </ins> Digital Map should contain only topological information.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Related discussion:
text: identify topological entities at different layers, identify their roles, and topological relationships between them. <del> Digital Map should contain only topological relationships inside each layer or between the layers (underlay/overlay). </del> <ins> Digital Map should contain all topological relationships inside each layer or between the layers (underlay/overlay) Digital Map should contain links to other models/data to enable generic navigation to other YANG models in generic way. </ins> Provide capability for conditional retrieval of parts of Digital Map. Must support geo-spatial, temporal, and historical data.  The <del> temporal and historical can be supported external to the Digital Map. </del> <ins> temporal and historical can also be supported external to the Digital Map. </ins> 4.3. <del> The following are the architectural requirements for the Digital Map: </del> <ins> The following are the architectural requirements for the controller that provides Digital Map API: </ins> Scale, performance, ease of integration.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Related discussion:
text: 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 <del> operator troubleshooting or optimizating the routing, while the </del> <ins> operator troubleshooting or optimizing the routing, while the </ins> optical layer may be of interest to the user managing the optical network.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Related discussion:
text: operations use cases, but it is also a requirement for the Digital Twin. <del> The following sections shows some example use case descriptions to initiate the discussion what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases, from the perspective of what is the value of the digital map for each use case and how the Digital Map API can be used.  This will also clarify if only read and if/when write interface is needed per use case. </del> <ins> The following sections includes some initial use case descriptions to initiate the discussion about what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases and more input from the operaotors, from the perspective of what the value of the digital map for each use case is and how the Digital Map API can be used. This will also clarify if only read and if/when write interface is needed per use case. </ins> 3.1.
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Related discussion:
text: 3.3. The application will be able to retrieve all services from the <del> Digital Map API for selected network type.  The application will be </del> <ins> Digital Map API for selected network types.  The application will be </ins> able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it
Code change:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Related discussion:
text: The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example, <del> the application will be able to select the resouce and by navigation </del> <ins> the application will be able to select the resouce and by navigating </ins> the supporting relationship bottom-up come to the service and its nodes, tps and links.