Operations and Management Area Working Group L. Li Internet-Draft Zhongguancun Laboratory Intended status: Standards Track Y. Cui Expires: 20 December 2026 Tsinghua University 18 June 2026 A YANG Data Model for Network Attack Sample Metadata draft-li-opsawg-attack-sample-metadata-00 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. Li & Cui Expires 20 December 2026 [Page 1] Internet-Draft NASM June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Relationship to OPSAWG and Existing Data Models . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 4.1. Architecture Diagram . . . . . . . . . . . . . . . . . . 5 4.2. Component Relationships . . . . . . . . . . . . . . . . . 6 4.3. Interoperability with Existing Standards . . . . . . . . 7 5. Attack Sample Module . . . . . . . . . . . . . . . . . . . . 7 5.1. sample-metadata . . . . . . . . . . . . . . . . . . . . . 7 5.2. attack-context . . . . . . . . . . . . . . . . . . . . . 10 5.3. data-content . . . . . . . . . . . . . . . . . . . . . . 11 5.4. reproducibility-context . . . . . . . . . . . . . . . . . 12 5.5. Top-Level Structure . . . . . . . . . . . . . . . . . . . 13 6. YANG Data Module . . . . . . . . . . . . . . . . . . . . . . 13 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Collected Attack Data Packages . . . . . . . . . . . . . 20 7.2. Cross-Domain DDoS Analysis . . . . . . . . . . . . . . . 20 7.3. Tool Validation and Regression Testing . . . . . . . . . 21 7.4. Operational Dataset Management . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.1. Sensitivity of Attack Sample Data . . . . . . . . . . . . 22 9.2. Access Control . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Li & Cui Expires 20 December 2026 [Page 2] Internet-Draft NASM June 2026 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: * Attack sample metadata and versioning * Attack classification, behavior, and lifecycle stages * Data content (packet, flow, session, payload) * Reproducibility information (environment, tools, parameters) * Interoperability with IPFIX, IODEF, collected data manifests, PCAP/PCAPng data, and operational analysis tools Li & Cui Expires 20 December 2026 [Page 3] Internet-Draft NASM June 2026 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: * The OPSAWG collected data manifest can describe broader data collection packages, while this model describes the attack sample contained in, or referenced by, such packages. * IPFIX records, packet captures, session logs, and application logs can be referenced or summarized by the data-content part of this model. * IODEF can describe an incident object, while this model can describe a packet, flow, session, or log sample associated with that incident. * NMOP anomaly and incident models can reference or consume samples described by this model, without this document redefining anomaly semantics or incident lifecycle management. 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. Li & Cui Expires 20 December 2026 [Page 4] Internet-Draft NASM June 2026 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 Li & Cui Expires 20 December 2026 [Page 5] Internet-Draft NASM June 2026 +--------------------------------------------------------------------------+ | 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. Li & Cui Expires 20 December 2026 [Page 6] Internet-Draft NASM June 2026 * 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; Li & Cui Expires 20 December 2026 [Page 7] Internet-Draft NASM June 2026 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. Li & Cui Expires 20 December 2026 [Page 8] Internet-Draft NASM June 2026 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."; } Li & Cui Expires 20 December 2026 [Page 9] Internet-Draft NASM June 2026 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; Li & Cui Expires 20 December 2026 [Page 10] Internet-Draft NASM June 2026 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. Li & Cui Expires 20 December 2026 [Page 11] Internet-Draft NASM June 2026 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. Li & Cui Expires 20 December 2026 [Page 12] Internet-Draft NASM June 2026 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; Li & Cui Expires 20 December 2026 [Page 13] Internet-Draft NASM June 2026 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."; } Li & Cui Expires 20 December 2026 [Page 14] Internet-Draft NASM June 2026 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 { Li & Cui Expires 20 December 2026 [Page 15] Internet-Draft NASM June 2026 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; Li & Cui Expires 20 December 2026 [Page 16] Internet-Draft NASM June 2026 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."; } Li & Cui Expires 20 December 2026 [Page 17] Internet-Draft NASM June 2026 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; Li & Cui Expires 20 December 2026 [Page 18] Internet-Draft NASM June 2026 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."; } } Li & Cui Expires 20 December 2026 [Page 19] Internet-Draft NASM June 2026 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, Li & Cui Expires 20 December 2026 [Page 20] Internet-Draft NASM June 2026 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. Li & Cui Expires 20 December 2026 [Page 21] Internet-Draft NASM June 2026 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, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . 10.2. Informative References Li & Cui Expires 20 December 2026 [Page 22] Internet-Draft NASM June 2026 [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, September 2013, . [RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [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, 20 October 2025, . [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, 19 January 2026, . [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, 13 February 2026, . Li & Cui Expires 20 December 2026 [Page 23] Internet-Draft NASM June 2026 Acknowledgements Thanks to Mingzhe Xing for his contribution to this draft. Authors' Addresses Linzhe Li Zhongguancun Laboratory Beijing 100094 China Email: lilz@zgclab.edu.cn Yong Cui Tsinghua University Beijing, 100084 China Email: cuiyong@tsinghua.edu.cn URI: http://www.cuiyong.net/ Li & Cui Expires 20 December 2026 [Page 24]