jiebi/CodeConvo huggingface dataset:
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.
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.
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
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.
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.
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
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
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
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.
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.
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.
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.
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.
The document defines the following terms: <del> Digital Map is a data model that provides a view of the operator's </del> <ins> SIMAP is a data model that provides a view of the operator's </ins> 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 <del> amongs layers and correlate between them.  This model is </del> <ins> amongs layers and correlate between them.  This includes layers from physical topology to service topology.  This model is </ins> applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). The set of principles, guidelines, and conventions to model the <del> 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 entities. </del> <ins> Service & Infrastructure Maps (SIMAP) 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 entities. </ins> Defines the core topological entities, their role in the network, core topological properties and relationships both inside each
3.5. The application will be able to retrieve topology layer and any <del> 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. </del> <ins> network/node/tp/link instances from the controller via the SIMAP 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. </ins> 3.6. The application will be able to retieve the topology at any layer <del> from the controller via Digital Map API and from the response it will </del> <ins> from the controller via the SIMAP API and from the response it will </ins> be able to navigate any retrieve any KPIs for selected topology entity.
A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a <del> network service.  Different data sources including alarms, metrics </del> <ins> network service.  Different data sources including alarms, metrics, </ins> and other anomaly information can be aggregated into few amount of network incidents by data correlation analysis and the service impact analysis. This document defines YANG Modules for the network incident lifecycle <del> management.  The YANG modules are meant to provide a standard way to report, diagnose, and resolve network incidents for the sake of </del> <ins> management.  These YANG modules are meant to provide a standard way to report, diagnose, and resolve network incidents for the sake of </ins> network service health and root cause analysis. 1. RFC8969 defines a framework for Automating Service and Network <del> Management with YANG to full life cycle network management.  A set of YANG data models have already been developed in IETF for Network performance monitoring and fault monitoring,e.g.,A YANG RFC7950 data model for alarm management RFC8632 defines a standard interface for alarm management.  A data model for Network and VPN Service </del> <ins> Management with YANG RFC7950 to full life cycle network management. A set of YANG data models have already been developed in IETF for network performance monitoring and fault monitoring, e.g., a YANG data model for alarm management RFC8632 defines a standard interface for alarm management.  A data model for Network and VPN Service </ins> Performance Monitoring RFC9375 defines a standard interface for network performance management.  In addition, distributed tracing <del> mechanism defined in W3C-Trace-Context can also be used to analyze and debug operations, such as configuration transactions, across multiple distributed systems. </del> <ins> mechanism defined in W3C-Trace-Context can be used to analyze and debug operations, such as configuration transactions, across multiple distributed systems. </ins> <del> However these YANG data models for network maintenance are based on </del> <ins> However, these YANG data models for network maintenance are based on </ins> specific data source information and manage alarms and performance metrics data separately by different layers in various different management systems.  In addition, the frequency and quantity of
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> The following terms are defined in RFC8632 and are not redefined here:
The following terms are defined in this document: <del> Network Incident: An unexpected interruption of a network service, degradation of network service quality, or sub-health of a network service TMF724A. Problem: The cause of one or more incidents.  The cause is not usually known when a problem record is created, and the problem management process is responsible for further investigation TMF724A. Incident management: Lifecycle management of incidents including incident identification, reporting, acknowledge, diagnosis, and resolution. Incident management system: An entity which implements incident management.  It include incident management server and incident management client. Incident management server: An entity which provides some functions of incident management.  For example, it can detect an incident, perform incident diagnosis, resolution and prediction,etc. Incident management client: An entity which can manage incidents. For example, it can receive incident notifications, query the information of incidents, instruct the incident management server to diagnose, resolve, etc. </del> 3. 3.1. <del> Traditionally, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers.  These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </del> <ins> Usually, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers. These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </ins> Some operators preconfigure whitelist and adopt some coarse granularity data correlation rules for the alarm management.  It
Abstract This specification defines a new method of client authentication for <del> OAuth2 RFC6749 by extending the approach defined in RFC7523.  This </del> <ins> OAuth2 RFC6749 by extending the approach defined in RFC7521.  This </ins> new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attested key based authentication scheme. 1. <del> RFC7523 defines a way for a client to include an assertion in a token </del> <ins> RFC7521 defines a way for a client to include an assertion in a token </ins> request to an authorization server for the purposes of client authentication.  This specification extends this mechanism to provide a way for a client instance to authenticate it self with the
the time window during which the JWT can be used.  The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. <del> Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. </del> The JWT MUST contain an "cnf" claim conforming RFC7800 that conveys the key to be used for sender constraining tokens issued