Internet-Draft NASM June 2026
Li & Cui Expires 20 December 2026 [Page]
Workgroup:
Operations and Management Area Working Group
Internet-Draft:
draft-li-opsawg-attack-sample-metadata-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
L. Li
Zhongguancun Laboratory
Y. Cui
Tsinghua University

A YANG Data Model for Network Attack Sample Metadata

Abstract

Operational analysis, troubleshooting, validation of network defense functions, and exchange of collected traffic evidence rely on attack samples that are consistently described and can be processed across operators, vendors, and research tools. Today, such samples are often represented by proprietary labels, partial traffic captures, flow exports, log bundles, or local database schemas, which makes comparison, reproduction, and automated processing difficult.

This document defines a YANG data model for network attack sample metadata. The model describes the sample identity, collection context, attack characteristics, data-content summary, anonymization status, and reproducibility information associated with packet, flow, session, log, or payload data. The model is intended to complement IPFIX, IODEF, PCAP/PCAPng-based operational data, and collected data manifests by defining metadata for the attack sample itself.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 December 2026.

Table of Contents

1. Introduction

Network attacks continue to grow in volume, sophistication, and operational impact. Operators need to correlate observations, troubleshoot incidents, validate mitigation functions, exchange selected evidence, and compare operational tools across heterogeneous networks. These activities rely on high-quality samples of observed attack behavior, together with enough metadata to understand how the sample was collected, sanitized, represented, and interpreted.

Today, there is no standardized way to describe, structure, label, archive, or share such attack samples in a consistent and interoperable manner. Samples are commonly stored as local packet captures, flow exports, log bundles, or data-set entries with proprietary labels. Important context such as observation point, topology, collection device, affected service, anonymization status, data-source type, and reproduction conditions is often missing or encoded in non-machine-readable form. This makes it difficult to reuse samples across tools, validate mitigation behavior, or exchange operational evidence between operators and tool vendors.

Existing IETF work covers related but different aspects of this problem. IPFIX [RFC7011] defines export of flow information. IODEF [RFC7970] describes incident objects. The Collected Data Manifest [I-D.ietf-opsawg-collected-data-manifest] describes metadata for collected operational data packages. NMOP work on network anomaly semantics [I-D.ietf-nmop-network-anomaly-semantics] and network incident management [I-D.ietf-nmop-network-incident-yang] can consume or reference attack samples as operational evidence, but those documents do not define a sample-level metadata model for packet, flow, session, log, or payload artifacts. This document complements those efforts by defining a YANG data model for the metadata of the attack sample itself.

The model provides a common, extensible framework to represent:

This model enables shareable, analyzable, reproducible, and machine-readable samples for operational analysis, incident support, mitigation validation, ML-based evaluation, rule validation, and data-set management.

2. Relationship to OPSAWG and Existing Data Models

The Operations and Management Area Working Group (OPSAWG) develops operationally useful specifications, including YANG data models and mechanisms for operational data exchange, when the work is not better handled by a more specialized working group. This document is scoped to that OPSAWG role. It does not define a new attack-detection algorithm, a new DDoS mitigation protocol, or a threat-intelligence exchange protocol. Instead, it defines an operational metadata model that can be used by collectors, management systems, controllers, analysis tools, and data repositories to describe attack samples and the data artifacts associated with them.

The model is intended to be used with, and not replace, the following work:

3. Terminology

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.

Attack Sample: A structured collection of network data (packet, flow, session, log, or payload metadata) that represents one or more attack behaviors, together with labels and operational context.

Operational Attack Sample: An attack sample used for operational analysis, mitigation validation, data-set management, or evidence exchange.

4. Architecture Overview

This document defines a unified data model for describing network attack samples with operational context. The architecture is YANG-based, lightweight, interoperable with existing IETF standards, and intended for operational analysis, mitigation validation, ML evaluation, sample archiving, verification, and sharing. The attack sample description is composed of five core components: * Sample Metadata * Collection Context (time, device, environment) * Attack Context (path, type, stage, technique, affected service) * Data Content (packet, flow, session, payload) * Reproducibility Context (tools, parameters, data-set version, replay or generation conditions) These components form a self-contained, machine-readable attack sample object that complements but does not overlap with IPFIX, IODEF, collected data manifests, or packet-capture formats.

4.1. Architecture Diagram

+--------------------------------------------------------------------------+
|                          Network Attack Sample Object                    |
|                                                                          |
|  +-------------------+  +---------------------------------------------+  |
|  |  1. Sample Meta   |  |  2. Collection Context                      |  |
|  |  - ID, Version    |  |  - Collection Time (Start/End)              |  |
|  |  - Author/Source  |  |  - Collecting Device (Vendor, Type, OS)     |  |
|  |  - Usage/License  |  |  - Observation Point / Topology             |  |
|  |  -  Anonymization |  |  - Data Source (PCAP/Flow/Session/Log)      |  |
|  +-------------------+  +---------------------------------------------+  |
|                                                                          |
|  +--------------------------------------------------------------------+  |
|  |  3. Attack Context                                                 |  |
|  |  - Attack Path (source -> target -> lateral -> C2 -> exfiltration)  |
|  |  - Attack Category / External Taxonomy Reference                    |  |
|  |  - Lifecycle Stage (recon -> exploit -> C2 -> exfiltration)         |  |
|  |  - Target Vulnerability / Affected Service                         |  |
|  +--------------------------------------------------------------------+  |
|                                                                          |
|  +--------------------------------------------------------------------+  |
|  |  5. Reproducibility Context                                        |  |
|  |  - Dataset Version / Generation Tool / Replay Parameters           |  |
|  |  - Sanitization and Anonymization Procedure                        |  |
|  |  - Validation Result References                                    |  |
|  +--------------------------------------------------------------------+  |
|                                                                          |
|  +--------------------------------------------------------------------+  |
|  |  4. Data Content Description                                       |  |
|  |  - Packet-level (Headers, Payload, Fingerprints)                   |  |
|  |  - Flow-level (IPFIX-compatible statistics)                        |  |
|  |  - Session-level Behavior (Timing, Rate, Direction, Ratios)        |  |
|  |  - Traffic Features (Entropy, Flag Patterns, Unusual Behavior)     |  |
|  +--------------------------------------------------------------------+  |
|                                                                          |
+--------------------------------------------------------------------------+
                                  |
                                  v
    Interoperability Layer (IPFIX / IODEF / Data Manifest / PCAP)

                 Figure 1: Architecture Diagram

4.2. Component Relationships

  • Collection Context provides when, where, and by which device the sample was captured.

  • Attack Context describes how the attack behavior appears and how it is classified.

  • Data Content is the raw network evidence (packet/flow/session).

  • Reproducibility information ensures the sample can be regenerated for verification.

4.3. Interoperability with Existing Standards

  • IPFIX provides flow data used in Data Content.

  • The Collected Data Manifest provides device and collection metadata that can be reused by Collection Context.

  • NMOP anomaly and incident models can reference samples described by this model as operational evidence where applicable.

  • IODEF incidents can be generated from, or linked to, labeled attack samples.

5. Attack Sample Module

This section defines the core logical data model for Network Attack Sample Description in accordance with YANG 1.1 RFC7950 [RFC8340]. The model is modular, reusable, and compatible with IPFIX [RFC7011], the Collected Data Manifest [I-D.ietf-opsawg-collected-data-manifest], IODEF [RFC7970], packet-capture data, and operational analysis tools. The model is structured into five groupings that represent the logical components of an attack sample: * sample-metadata * collection-context * attack-context * data-content * reproducibility-context

5.1. sample-metadata

The sample-metadata grouping provides unique identification and management information for an attack sample.

grouping sample-metadata {
  leaf sample-id {
    type string;
    description
      "Unique identifier for the attack sample. A UUID is RECOMMENDED.";
  }
  leaf sample-version {
    type string;
    description
      "Version identifier of the attack sample.";
  }
  leaf sample-name {
    type string;
    description
      "Human-readable name of the attack sample.";
  }
  leaf description {
    type string;
    description
      "Detailed description of the attack scenario.";
  }
  leaf creator {
    type string;
    description
      "Creator or organization that produced the sample.";
  }
  leaf creation-time {
    type yang:date-and-time;
    description
      "Time when the attack sample was created.";
  }
  leaf usage-scope {
    type enumeration {
      enum training;
      enum testing;
      enum analysis;
      enum rule-verification;
      enum research;
    }
    description
      "Intended usage of the attack sample.";
  }
  leaf anonymization {
    type enumeration {
      enum none;
      enum partial;
      enum full;
    }
    description
      "Level of anonymization applied to the sample.";
  }
}

## collection-context The collection-context grouping describes when, where, and by which device the attack sample was collected.

grouping collection-context {
  leaf collection-start-time {
    type yang:date-and-time;
    description
      "Start time of the data collection interval.";
  }
  leaf collection-end-time {
    type yang:date-and-time;
    description
      "End time of the data collection interval.";
  }
  leaf collecting-device-type {
    type enumeration {
      enum router;
      enum switch;
      enum firewall;
      enum probe;
      enum host;
      enum controller;
    }
    description
      "Type of device that collected the traffic.";
  }
  leaf device-vendor {
    type string;
    description
      "Vendor of the collecting device.";
  }
  leaf device-model {
    type string;
    description
      "Hardware model of the collecting device.";
  }
  leaf os-version {
    type string;
    description
      "Operating system or firmware version.";
  }
  leaf observation-point {
    type string;
    description
      "Capture point: ingress interface, mirror port, or sensor location.";
  }
  leaf topology-desc {
    type string;
    description
      "Brief network topology description.";
  }
  leaf data-source-type {
    type enumeration {
      enum pcap;
      enum flow;
      enum session;
      enum log;
      enum payload;
    }
    description
      "Underlying data format of the sample.";
  }
}

5.2. attack-context

The attack-context grouping describes attack behavior, attack path, lifecycle, and tactics.

grouping attack-context {
  leaf attack-path {
    type string;
    description
      "Full attack path, e.g., attacker -> target -> lateral -> C2 -> exfiltration.";
  }
  leaf attack-category {
    type enumeration {
      enum reconnaissance;
      enum brute-force;
      enum dos;
      enum exploitation;
      enum malware;
      enum c2;
      enum tunneling;
      enum data-exfiltration;
    }
    description
      "High-level attack category.";
  }
  leaf attack-technique {
    type string;
    description
      "MITRE ATT&CK technique identifier (optional).";
  }
  leaf attack-stage {
    type enumeration {
      enum reconnaissance;
      enum exploitation;
      enum persistence;
      enum c2;
      enum exfiltration;
    }
    description
      "Attack lifecycle stage.";
  }
  leaf attack-intent {
    type enumeration {
      enum disruption;
      enum info-disclosure;
      enum privilege-escalation;
      enum data-theft;
    }
    description
      "Intended goal of the attack.";
  }
  leaf targeted-cve {
    type string;
    description
      "Targeted CVE identifier if applicable.";
  }
  leaf affected-service {
    type string;
    description
      "Affected protocol or service.";
  }
}

5.3. data-content

The data-content grouping describes what network data is included in the attack sample.

grouping data-content {
  leaf packet-included {
    type boolean;
    description
      "Whether full packet data is included.";
  }
  leaf flow-included {
    type boolean;
    description
      "Whether flow records (IPFIX-compatible) are included.";
  }
  leaf payload-included {
    type boolean;
    description
      "Whether application-layer payloads are included.";
  }
  leaf flow-count {
    type uint32;
    description
      "Total number of flow records in the sample.";
  }
  leaf packet-count {
    type uint64;
    description
      "Total number of packets in the sample.";
  }
  leaf duration {
    type yang:timedelta;
    description
      "Total time duration covered by the sample.";
  }
  leaf-list flow-attributes {
    type string;
    description
      "List of flow attributes included (e.g., 5-tuple, packet-count, flags).";
  }
}

5.4. reproducibility-context

The reproducibility-context grouping describes the information needed to replay, regenerate, validate, or compare a sample in an operational test or incident-analysis workflow.

grouping reproducibility-context {
  leaf dataset-version {
    type string;
    description
      "Version of the dataset or corpus that contains this sample.";
  }
  leaf generation-tool {
    type string;
    description
      "Tool, generator, replay system, or collector used to produce the sample.";
  }
  leaf generation-parameters {
    type string;
    description
      "Parameters used to generate or replay the sample. Sensitive values
       SHOULD be omitted, redacted, or referenced through controlled access.";
  }
  leaf sanitization-method {
    type string;
    description
      "Anonymization, minimization, or sanitization method applied to the sample.";
  }
  leaf validation-reference {
    type string;
    description
      "Reference to validation results, detection-rule evaluation, or incident-analysis output.";
  }
}

5.5. Top-Level Structure

A complete attack sample combines all five groupings:

grouping attack-sample {
  uses sample-metadata;
  uses collection-context;
  uses attack-context;
  uses data-content;
  uses reproducibility-context;
  description
    "Top-level grouping that represents a full network attack sample.";
}

6. YANG Data Module

file "ietf-attack-sample@2026-05-15.yang" module ietf-attack-sample { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-attack-sample"; prefix attack-sample;

import ietf-yang-types {
  prefix yang;
  reference "RFC 6991: YANG Common Data Types";
}

organization
  "IETF OPSAWG Working Group";
contact
  "WG Web: https://datatracker.ietf.org/wg/opsawg/";
description
  "This module defines a data model for describing network attack
  samples with operational context, including collection context,
  attack characteristics, data-content summary, and reproducibility
  information.

  Copyright (c) 2026 IETF Trust and the persons identified as
  authors of the code. All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, is permitted pursuant to, conditional upon the
  compliance with IETF Trust Provisions and disclaimers.

  This version of this YANG module is part of RFC XXXX; see the RFC
  itself for full legal notices.";

revision 2026-05-15 {
  description "Initial version";
  reference "RFC XXXX: A YANG Data Model for Network Attack Sample Metadata";
}

grouping sample-metadata {
  description
    "Identification and management information for an attack sample.";
  leaf sample-id {
    type string;
    description
      "Unique identifier for the sample. A UUID is RECOMMENDED.";
  }
  leaf sample-version {
    type string;
    description
      "Version identifier of the sample.";
  }
  leaf sample-name {
    type string;
    description
      "Human-readable name of the sample.";
  }
  leaf description {
    type string;
    description
      "Detailed description of the attack scenario.";
  }
  leaf creator {
    type string;
    description
      "Creator or organization that produced the sample.";
  }
  leaf creation-time {
    type yang:date-and-time;
    description
      "Time when the sample metadata was created.";
  }
  leaf usage-scope {
    type enumeration {
      enum training;
      enum testing;
      enum analysis;
      enum rule-verification;
      enum research;
      enum incident-evidence;
    }
    description
      "Intended operational usage of the sample.";
  }
  leaf anonymization {
    type enumeration {
      enum none;
      enum partial;
      enum full;
    }
    description
      "Level of anonymization applied to the sample.";
  }
}

grouping collection-context {
  description
    "Information describing when, where, and by which device the
    sample was collected.";
  leaf collection-start-time {
    type yang:date-and-time;
    description
      "Start time of the data collection interval.";
  }
  leaf collection-end-time {
    type yang:date-and-time;
    description
      "End time of the data collection interval.";
  }
  leaf collecting-device-type {
    type enumeration {
      enum router;
      enum switch;
      enum firewall;
      enum probe;
      enum host;
      enum controller;
    }
    description
      "Type of device that collected the traffic or telemetry.";
  }
  leaf device-vendor {
    type string;
    description
      "Vendor of the collecting device.";
  }
  leaf device-model {
    type string;
    description
      "Hardware model of the collecting device.";
  }
  leaf os-version {
    type string;
    description
      "Operating system or firmware version.";
  }
  leaf observation-point {
    type string;
    description
      "Capture point, such as an ingress interface, mirror port, or
      sensor location.";
  }
  leaf topology-desc {
    type string;
    description
      "Brief network topology description.";
  }
  leaf-list data-source-type {
    type enumeration {
      enum pcap;
      enum flow;
      enum session;
      enum log;
      enum payload;
    }
    description
      "Underlying data formats represented by the sample.";
  }
}

grouping attack-context {
  description
    "Information describing the observed attack behavior.";
  leaf attack-path {
    type string;
    description
      "Observed or inferred attack path.";
  }
  leaf attack-category {
    type enumeration {
      enum reconnaissance;
      enum brute-force;
      enum dos;
      enum exploitation;
      enum malware;
      enum c2;
      enum tunneling;
      enum data-exfiltration;
      enum other;
    }
    description
      "High-level attack category.";
  }
  leaf attack-technique {
    type string;
    description
      "External taxonomy identifier, if applicable.";
  }
  leaf attack-stage {
    type enumeration {
      enum reconnaissance;
      enum exploitation;
      enum persistence;
      enum c2;
      enum exfiltration;
      enum mitigation;
      enum unknown;
    }
    description
      "Observed lifecycle stage.";
  }
  leaf attack-intent {
    type enumeration {
      enum disruption;
      enum info-disclosure;
      enum privilege-escalation;
      enum data-theft;
      enum unknown;
    }
    description
      "Inferred intent of the observed behavior.";
  }
  leaf targeted-cve {
    type string;
    description
      "Targeted CVE identifier, if applicable.";
  }
  leaf affected-service {
    type string;
    description
      "Affected protocol, application, or network service.";
  }
}

grouping data-content {
  description
    "Summary of the network data included in or referenced by the sample.";
  leaf packet-included {
    type boolean;
    description
      "Whether full packet data is included.";
  }
  leaf flow-included {
    type boolean;
    description
      "Whether flow records are included.";
  }
  leaf payload-included {
    type boolean;
    description
      "Whether application-layer payloads are included.";
  }
  leaf flow-count {
    type uint32;
    description
      "Total number of flow records in the sample.";
  }
  leaf packet-count {
    type uint64;
    description
      "Total number of packets in the sample.";
  }
  leaf duration {
    type string;
    description
      "Total time duration covered by the sample.";
  }
  leaf-list flow-attributes {
    type string;
    description
      "List of flow attributes included, such as 5-tuple,
      packet-count, or flags.";
  }
}

grouping reproducibility-context {
  description
    "Information needed to replay, regenerate, validate, or compare
    the sample.";
  leaf dataset-version {
    type string;
    description
      "Version of the dataset or corpus that contains this sample.";
  }
  leaf generation-tool {
    type string;
    description
      "Tool, generator, replay system, or collector used to produce the sample.";
  }
  leaf generation-parameters {
    type string;
    description
      "Parameters used to generate or replay the sample.";
  }
  leaf sanitization-method {
    type string;
    description
      "Anonymization, minimization, or sanitization method applied to the sample.";
  }
  leaf validation-reference {
    type string;
    description
      "Reference to validation results, detection-rule evaluation, or
      incident-analysis output.";
  }
}

grouping attack-sample {
  description
    "Complete attack sample metadata.";
  uses sample-metadata;
  uses collection-context;
  uses attack-context;
  uses data-content;
  uses reproducibility-context;
}

container attack-samples {
  config false;
  description
    "Top-level container for network attack samples.";

  list attack-sample {
    key "sample-id";
    description
      "A single, fully contextualized network attack sample.";
    uses attack-sample;
  }
}   }

7. Use Cases

7.1. Collected Attack Data Packages

Operators may collect packet captures, IPFIX records, session logs, controller events, and mitigation logs from different observation points during an attack. These artifacts are often stored together as an operational data package, but the attack-specific meaning of the package is not always machine-readable. The model defined in this document can describe the sample identity, collection context, attack category, data content, anonymization status, and reproducibility information associated with those artifacts. This allows a collected data manifest to describe the package as a whole, while this model describes the attack sample contained in or referenced by that package.

7.2. Cross-Domain DDoS Analysis

When an enterprise network suffers from a large-scale DDoS attack, it may need to share selected attack characteristics with an upstream provider or mitigation service. In such scenarios, sending raw traffic is often impractical or undesirable because of volume, privacy, and operational sensitivity. The attack sample model defined in this document provides a compact and interoperable description of attack characteristics, including attack category, traffic distribution, packet or flow features, observation point, affected service, and anonymization status. This allows the receiving operator to understand the relevant evidence and formulate mitigation actions, while minimizing unnecessary exposure of raw data.

7.3. Tool Validation and Regression Testing

Operators and vendors often need to validate detection, filtering, traffic-cleaning, flow-analysis, and reporting tools against known attack samples. Without common sample metadata, two tools can process the same packet capture or flow set but interpret the collection point, label, time interval, anonymization level, or expected behavior differently. The model defined in this document enables repeatable testing and comparison by carrying the operational context and reproduction information with the sample.

7.4. Operational Dataset Management

Operators, vendors, and researchers maintain datasets for ML training, rule validation, regression testing, and operational readiness exercises. Such datasets are difficult to reuse when labels, collection parameters, sanitization methods, and validation results are not represented consistently. The model defined in this document provides metadata that can travel with a dataset or be referenced from a collected data manifest. This makes samples easier to index, compare, reproduce, and safely exchange.

8. IANA Considerations

This document includes no request to IANA.

9. Security Considerations

This YANG data model defines structured descriptions of network attack samples, including attack behavior, traffic characteristics, payload fingerprints, collection context, and reproduction parameters. Sensitive information in this model requires careful security controls to prevent misuse, unauthorized access, or exposure to malicious parties.

9.1. Sensitivity of Attack Sample Data

Attack samples described by this model may contain highly sensitive information: * Exact attack methods, tools, and commands that could be reused for malicious activity * Network topology, device types, and deployment details of production environments * Payloads, fingerprints, and IoCs that reveal defense mechanisms * Labeled data that discloses internal detection rules and policies Unauthorized disclosure of such data could enable adversaries to improve attacks, evade defenses, or target specific network environments.

9.2. Access Control

All read and query operations to the attack-sample data model MUST be restricted through strong authentication and authorization mechanisms. Implementations MUST use secure management protocols such as: * NETCONF over SSH (RFC 6241, RFC 6242) * RESTCONF over TLS 1.3 (RFC 8040, RFC 8446) Access control MUST follow the principle of least privilege. The Network Configuration Access Control Model (NACM, RFC 8341) SHOULD be used to restrict access to the attack-samples container and related components.

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC6991]
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, , <https://www.rfc-editor.org/rfc/rfc6991>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8340]
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/rfc/rfc8340>.

10.2. Informative References

[RFC7011]
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, , <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7970]
Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, , <https://www.rfc-editor.org/rfc/rfc7970>.
[RFC8341]
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/rfc/rfc8341>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/rfc/rfc8040>.
[I-D.ietf-opsawg-collected-data-manifest]
Claise, B., Quilbeuf, J., Lopez, D., Martinez-Casanueva, I. D., and T. Graf, "A Data Manifest for Contextualized Telemetry Data", Work in Progress, Internet-Draft, draft-ietf-opsawg-collected-data-manifest-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-collected-data-manifest-10>.
[I-D.ietf-nmop-network-anomaly-semantics]
Graf, T., Du, W., Feng, A. H., and V. Riccobene, "Semantic Metadata Annotation for Network Anomaly Detection", Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly-semantics-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-semantics-05>.
[I-D.ietf-nmop-network-incident-yang]
Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-08>.

Acknowledgements

Thanks to Mingzhe Xing for his contribution to this draft.

Authors' Addresses

Linzhe Li
Zhongguancun Laboratory
Beijing
100094
China
Yong Cui
Tsinghua University
Beijing, 100084
China