]> e.Mix

BR royoshioka@gmail.com

OrcaTI

BR guilabadessa@gmail.com

Sysbrasil Tecnologia

BR pedroscalon01@gmail.com

Vero Internet

BR diegocdeb@hotmail.com

Zadara

BR ebelotto@gmail.com

OPS DISPATCH Working Group backup YANG JSON archive integrity canonical SNAP (Simple Native Archive Protocol) defines a minimal, self-describing backup object encoded as a single JSON document, modeled in YANG and encoded per . A SNAP object contains a manifest of files with per-file cryptographic hashes, integrity-verified metadata, and a compressed binary payload -- all within one atomic, transport-agnostic JSON document. Any agent capable of parsing JSON and applying standard decompression can produce or restore a SNAP backup without proprietary tooling, side-channel metadata, or multi-phase handshakes. This document defines the YANG module "snap", its JSON encoding, integrity verification procedure, bindings to common transports, and its role as the atomic transport substrate for the Multi-Vantage Path State (MVPS) family of Internet-Drafts. When a SNAP Object carries an MVPS Bundle , the canonical-form determinism of SNAP (Theorem 1 of this document) composes with the MVPS Architecture axioms A1..A5 to inherit the full coherence algebra of (Theorems 1, 2, 3, 3', 4, 5, 9 and Stein's Lemma ) without alteration. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the DISPATCH Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Existing backup solutions tightly couple data capture, transport, and restoration into proprietary stacks. A system administrator wishing to back up configuration files today must choose between raw archives (POSIX tar, IEEE Std 1003.1), complex multi-phase protocols (rsync, BorgBackup), or vendor-specific agents. None of these produce a self-describing, cryptographically verifiable, machine-readable artifact that can be inspected, transported, and restored by any standards-compliant agent without prior knowledge of the producing system. SNAP addresses this gap by defining: A data model for backup objects expressed in YANG 1.1 , enabling schema validation by any YANG-capable tool. A canonical JSON encoding following , with deterministic serialization per the JSON Canonicalization Scheme to support reproducible integrity hashes. An integrity model based on SHA-256 applied to both individual files (in the manifest) and the envelope object (via JCS). A transport binding over HTTP/2 and WebSocket , with a size-aware atomicity requirement for small objects. The design philosophy of SNAP is conservative composition: every primitive is drawn from existing IETF or NIST standards. SNAP defines only the composition and the backup-specific YANG module.

Relationship to Existing Standards RFC 9195 defines the YANG Instance Data File Format, which provides a container for YANG-modeled data at rest. RFC 9195 is concerned with YANG schema instances (configuration and state data from YANG-modeled systems), not with arbitrary file collections. SNAP extends the spirit of RFC 9195 to the general file backup domain. The YANG provenance mechanism applies COSE signatures to YANG instance data. SNAP uses JCS-based SHA-256 rather than COSE because the backup payload is a binary blob rather than a YANG instance tree. YANG Packages define offline distribution of YANG schemas. SNAP is complementary: it backs up the operational data, not the schema.

Relationship to the MVPS Family SNAP is designed to compose with the Multi-Vantage Path State (MVPS) family of Internet-Drafts as their atomic transport substrate. This subsection summarizes the dependency. The MVPS family consists of nine related drafts (D-1 through D-7, D-15, D-16) whose mathematical authority is the v4.0 proof catalogue , validated against 37 adversarial attacks across seven audit rounds (44/44 PASS). The catalogue defines: A bundle algebra (D1, D3, F1-F4, I1) over coherence axes (C_1 causal, C_2 informational, C_3 topological) and a bounded scalar H : R^3 -> [0, H_max] with H_max = -3 log epsilon (Theorem 1). Detection statistics (Theorems 2, 3, 3') using the Mahalanobis statistic D^2 on the coherence vector C(t). A Byzantine breakdown bound (Theorem 9) of (2f / (N - 2f)) * sqrt(2) on geometric-median centroids for N vantages with f adversaries. Architectural axioms MVPS-A1..A5 and the Invariance Theorem: any architecture satisfying A1..A5 inherits Theorems 1, 2, 3, 3', 4, 5, 9 and Stein's Lemma verbatim. A Planetary Coherence Floor giving R* = max{tau_causal, tau_sampling, tau_information, tau_consensus, tau_coupling} as the lower bound for planet-scale detect-and-react. The MVPS Bundle is the canonical RFC 7951 envelope that carries a coordinated multi-vantage observation. A reference bundle contains a bundle_id (UUID v4 lowercase), a schema_version, a destination, a coordination_window, and an ordered array of per-vantage snapshots -- all serialized canonically per . Because the SNAP envelope shares the same canonicalization stack as the MVPS Bundle (RFC 7951 JSON encoding, JCS canonicalization, SHA-256 pinning, UUID v4 identifiers), an MVPS Bundle can be carried verbatim inside the SNAP payload field with no loss of structural or cryptographic guarantees. Section 8.2 (Appendix D) of this document proves the composition theorem and lists the operational contracts (OC1..OC8) of that MUST be preserved by SNAP encoders carrying MVPS data.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are used in this document:

SNAP Object:

A single JSON document conforming to the "snap" YANG module defined in . Also referred to as "backup object".

Manifest:

The ordered list of file entries within a SNAP Object. Each entry records the file path, size, modification time, and SHA-256 digest.

Payload:

The binary content of the backup: a compressed archive of all files listed in the Manifest, encoded in Base64 .

Encoder:

A process or system that produces a SNAP Object from a set of files.

Decoder:

A process or system that restores files from a SNAP Object.

JCS:

JSON Canonicalization Scheme , used to produce a deterministic byte sequence over which the envelope hash is computed.

SNAP Object Format A SNAP Object is a JSON object whose structure is fully specified by the YANG module in and encoded per .

Top-Level Structure The following is a non-normative illustration of a SNAP Object:

Field Definitions

version:

MUST be the string "1.0" for documents conforming to this specification. Future versions will use a new value.

id:

A UUID in its canonical textual representation. Encoders MUST generate version 4 (random) UUIDs. IDs MUST be unique across all SNAP Objects produced by an Encoder.

created:

The timestamp at which encoding began, as a date-and-time value (ISO 8601 format, UTC).

src:

A container identifying the origin of the backup. The "host" leaf is a fully qualified domain name or IP address of the source system. The "path" leaf is an absolute path on the source system.

meta:

Metadata about the encoded content. "files" is the count of entries in the manifest. "size-bytes" is the sum of sizes of all source files. "enc" identifies the compression algorithm applied to the payload (see ). "hash" is the envelope integrity hash (see ).

manifest:

An ordered list of file entries. Each entry MUST correspond to a file present in the payload. The "file" field is a relative path from "src/path". The "sha256" field is the lowercase hex-encoded SHA-256 digest of the uncompressed file content . The "size" field is the exact byte count of the uncompressed file. The "mtime" field is the last-modification timestamp.

payload:

The Base64-encoded compressed archive of all files listed in the manifest. The archive format is a POSIX-compliant tar stream. The compression algorithm is identified by "meta/enc".

Compression The "meta/enc" leaf identifies the compression applied to the tar stream before Base64 encoding. The following values are defined: Value Specification Recommended none No compression No gz Gzip No br Brotli YES zstd Zstandard No Encoders SHOULD use "br" (Brotli) as the default compression because Brotli consistently achieves compression ratios closest to the Shannon entropy bound for structured text data (configuration files, YANG instance data, scripts) while being an IETF-standardized algorithm. Decoders MUST support all four values.

Envelope Integrity The "meta/hash" field contains the envelope integrity hash in the format "sha256:<hex>", where <hex> is the lowercase hexadecimal encoding of a SHA-256 digest . The digest is computed over the canonical JSON serialization of the SNAP Object with the "meta/hash" field set to the empty string "". Canonical serialization follows the JSON Canonicalization Scheme . Formally, let O be the SNAP Object and O' be the object derived by setting O["snap:backup"]["meta"]["hash"] to "". Then:

Decoders MUST verify the envelope hash before restoring any file. Decoders MUST also verify each per-file "sha256" digest against the content extracted from the payload. A Decoder MUST NOT restore any file from a SNAP Object that fails either verification.

Canonical Form (Theorem of Determinism) A central property of SNAP is that any two conforming Encoders, given the same input files and metadata, MUST produce SNAP Objects with the same envelope hash. This subsection states the theorem and the implementation rules that guarantee it. Theorem 1 (Encoder Determinism). Let E1 and E2 be two conforming SNAP Encoders. Let F be a set of files with identical content, paths, sizes, and modification times. Let M = (id, created, host, path, enc) be identical metadata inputs. Then:

provided that "enc" specifies a deterministic compression algorithm (Section 6.1). The proof rests on three lemmas:

Lemma 1 (Tar determinism):

Given identical file contents and metadata, a SNAP-conforming tar archive MUST use the USTAR format (POSIX 1003.1-1988) with files listed in lexicographic order of relative path, with all extended attributes and ownership fields zeroed. Two such archives are byte-identical.

Lemma 2 (Compression determinism):

The codecs "br" (Brotli quality 11) and "gz" (gzip level 9, no filename, no timestamp) are deterministic functions of their input. Zstandard ("zstd") MUST use level 19 with no checksum frame for determinism.

Lemma 3 (JCS uniqueness, ):

For any JSON value V conforming to the I-JSON profile , the JCS canonicalization JCS(V) produces a unique byte sequence.

Combining the three lemmas, the inputs to SHA-256 are byte-identical across implementations; therefore the resulting "meta/hash" is identical. QED. Corollary 1 (Cross-vendor interoperability). Any SNAP Decoder that successfully verifies a SNAP Object produced by Encoder E1 will successfully verify the same Object regenerated by Encoder E2 from the same inputs.

YANG Module This section defines the normative YANG 1.1 module "snap".

Co-author: Guilherme Labadessa (OrcaTI) Co-author: Pedro Scalon (Sysbrasil Tecnologia) Co-author: Diego Canton de Brito (Vero Internet) Co-author: Eduardo Belotto (Zadara) Contributor: Leonardo Melegassi (Catellix) "; description "This module defines the data model for a SNAP backup object. SNAP (Simple Native Archive Protocol) encodes a complete file backup as a single JSON document. 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, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info)."; revision 2026-05-26 { description "Initial version."; reference "draft-melegassi-dispatch-mvps-snap-backup-01"; } typedef snap-version { type string { pattern '1\.[0-9]+'; } description "SNAP protocol version string. The format is MAJOR.MINOR. This document defines version 1.0."; } typedef compression-algorithm { type enumeration { enum none { value 0; description "No compression."; } enum gz { value 1; description "Gzip compression per RFC 1952."; reference "RFC 1952: GZIP file format specification"; } enum br { value 2; description "Brotli compression per RFC 7932. This is the RECOMMENDED algorithm."; reference "RFC 7932: Brotli Compressed Data Format"; } enum zstd { value 3; description "Zstandard compression per RFC 8878."; reference "RFC 8878: Zstandard Compression and the application/zstd Media Type"; } } description "Compression algorithm applied to the payload."; } typedef integrity-hash { type string { pattern 'sha256:[0-9a-f]{64}'; } description "An integrity hash in the format 'sha256:', where is the lowercase hexadecimal SHA-256 digest per FIPS 180-4. The value '' (empty string) is reserved for use during envelope hash computation."; } container backup { description "Root container for a SNAP backup object. A conforming JSON document contains exactly one instance of this container, under the key 'snap:backup'."; leaf version { type snap-version; mandatory true; description "SNAP protocol version. MUST be '1.0' for documents conforming to this specification."; } leaf id { type yang:uuid; mandatory true; description "Globally unique identifier for this backup object. Encoders MUST generate version 4 (random) UUIDs per RFC 4122."; reference "RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace"; } leaf created { type yang:date-and-time; mandatory true; description "Timestamp at which encoding began. MUST be in UTC (the time-offset MUST be '+00:00' or 'Z')."; } container src { description "Source identification for the backed-up data."; leaf host { type string { length "1..253"; } mandatory true; description "Fully qualified domain name or IP address of the system from which files were collected."; } leaf path { type string { pattern '/.*'; } mandatory true; description "Absolute path on the source system that is the root of the backed-up file tree."; } } container meta { description "Metadata about the backup content."; leaf files { type uint32; description "Number of file entries in the manifest. MUST equal the number of entries in the 'manifest' list."; } leaf size-bytes { type uint64; description "Sum of 'size' values of all manifest entries, in bytes. Represents the total uncompressed data size."; } leaf enc { type compression-algorithm; default "br"; description "Compression algorithm applied to the tar stream before Base64 encoding."; } leaf hash { type string; description "Envelope integrity hash. During encoding, this field is set to '' before computing the JCS digest, then replaced with 'sha256:'. Decoders MUST verify this field before restoring any file."; } } list manifest { key "file"; ordered-by user; description "Ordered list of file entries. The order MUST match the order of files in the tar stream within the payload."; leaf file { type string; description "Relative path of the file from 'src/path'. MUST use '/' as the path separator. MUST NOT begin with '/'."; } leaf sha256 { type string { pattern '[0-9a-f]{64}'; } mandatory true; description "Lowercase hex-encoded SHA-256 digest of the uncompressed file content."; } leaf size { type uint64; mandatory true; description "Uncompressed file size in bytes."; } leaf mtime { type yang:date-and-time; description "Last modification timestamp of the file."; } } leaf payload { type binary; mandatory true; description "Base64-encoded compressed tar archive of all files listed in the manifest. The compression algorithm is identified by 'meta/enc'."; } } } ]]>

Operations

Encoding a SNAP Object An Encoder MUST perform the following steps in order: Collect all files from the source path. For each file, compute the SHA-256 digest of its uncompressed content and record the file path, digest, size, and modification time. Construct a POSIX-compliant tar archive of all collected files, preserving relative paths from the source root. Compress the tar archive using the selected algorithm (RECOMMENDED: Brotli, "br"). Base64-encode the compressed archive per , Section 4 (standard encoding with padding). Construct the SNAP Object JSON document with all fields populated and "meta/hash" set to the empty string "". Compute JCS(O') where O' is the object from step 6. Set "meta/hash" to "sha256:" followed by the lowercase hexadecimal SHA-256 digest of JCS(O'). The resulting document is the SNAP Object.

Decoding and Restoring from a SNAP Object A Decoder MUST perform the following steps in order: Parse the JSON document and validate it against the "snap" YANG module. Reject documents that do not conform. Save the value of "meta/hash". Set "meta/hash" to "". Compute JCS(O') and verify that SHA-256(JCS(O')) equals the saved hash. Reject documents where the hash does not match. Base64-decode the "payload" field. Decompress the result using the algorithm identified by "meta/enc". Extract the tar archive. For each extracted file, compute its SHA-256 digest and compare it against the corresponding manifest entry. Reject the restoration if any digest does not match. Write each file to its target path. A Decoder MUST NOT write any file to disk until all digest verifications in step 6 have passed.

Transport Bindings SNAP Objects are transport-agnostic. This section defines bindings to common transports.

HTTP/2 and HTTP/1.1 A SNAP Object SHOULD be transported using the HTTP POST method with the following media type:

The "SNAP-Profile" header value is one of "minimal", "standard", or "full" and identifies the Encoder's conformance profile (Section 6). A Decoder receiving a profile it does not support MUST respond with HTTP 415 (Unsupported Media Type) and a body containing the list of supported profiles. The response to a successful POST MUST use HTTP status code 200 or 201. For objects whose serialized size does not exceed 65,535 bytes, the HTTP request MUST NOT use chunked transfer encoding (i.e., the object MUST be delivered atomically in a single HTTP request body).

WebSocket A SNAP Object MAY be transported as a single WebSocket binary frame . The frame payload is the UTF-8 encoded JSON document.

Size and Atomicity A SNAP Object whose serialized size is at most 14,600 bytes (10 TCP segments of 1,460 bytes, i.e., the typical TCP initial congestion window) will be delivered in a single TCP burst, achieving minimum transport latency:

where RTT is the round-trip time and B is the available bandwidth. This represents the theoretical minimum for any reliable, ordered transport: one RTT for connection establishment plus wire time. Implementations targeting minimum-latency backup SHOULD structure source trees such that a SNAP Object's compressed payload fits within this bound.

Conformance To enable interoperability across a wide range of vendor implementations (from embedded devices to enterprise backup systems), SNAP defines three conformance profiles. A conforming implementation MUST advertise its profile via the "SNAP-Profile" HTTP header (Section 5.1) or its equivalent at the application layer.

Profiles Profile Encoder MUST Decoder MUST Use case Minimal enc="none" or "gz" enc="none","gz" Constrained devices, embedded Standard enc="br" enc="none","gz","br" General-purpose, network nodes Full All four enc All four enc Backup servers, archivers All profiles MUST implement: JSON parsing per YANG schema validation per and JSON encoding per JCS canonicalization per SHA-256 per Base64 encoding per Section 4 USTAR archive format (POSIX 1003.1-1988) The integrity verification procedure of Section 4.2

Feature Matrix The following requirements apply to all profiles: Feature Encoder Decoder Notes Validate against YANG module MUST MUST Section 3 invariants I1-I5 Compute SHA-256 per file MUST MUST Manifest sha256 leaf Compute envelope SHA-256 via JCS MUST MUST Section 3.4 Reject on hash mismatch N/A MUST Section 4.2 step 6 Reject on schema violation MUST MUST Section 4.2 step 1 Generate UUID v4 MUST N/A Section 3.2 id field UTC timestamps MUST MUST invariant I5 Atomic delivery for <=65535 bytes MUST SHOULD Section 5.1 Decompression bomb limit N/A MUST Section 7.4 TLS 1.3 for sensitive data MUST MUST Section 7.2 Replay ID tracking SHOULD SHOULD Section 7.3 Encrypted payload MAY MAY Out of scope

Interoperability Test Suite A conforming implementation SHOULD pass the test vectors defined in . Implementers are RECOMMENDED to publish their conformance results to the SNAP interoperability matrix maintained at the GitHub repository listed in the document front matter.

Vendor Implementation Notes This subsection provides non-normative guidance for common implementation environments:

Embedded systems (Minimal profile):

Use gzip level 9 with mtime=0 and FNAME stripped (RFC 1952 Section 2.3.1). USTAR archive can be constructed in 512-byte blocks with constant memory. SHA-256 needs ~200 bytes of state. JCS for the SNAP envelope requires sorting only six top-level keys; a static comparator suffices.

Cloud and SaaS (Standard/Full profile):

Use Brotli with quality=11. Stream the tar+brotli pipeline to keep memory bounded. Compute per-file SHA-256 during tar emission to avoid a second file pass. JCS over the envelope requires the full document; payloads MAY be elided during canonicalization by hashing the Base64 string only.

Programming language ecosystems:

Reference implementations are RECOMMENDED to be published in at least one of: Go, Rust, Python, JavaScript. Implementers MUST use a JCS library that has passed the test vectors in Section 5; ad-hoc canonicalization implementations are a primary source of cross-vendor hash mismatches.

Security Considerations

Integrity The envelope hash ("meta/hash") uses SHA-256 over the JCS canonicalization of the SNAP Object. SHA-256 is a one-way function with a 256-bit output space. Under the birthday bound, the probability of finding two distinct SNAP Objects with the same hash is approximately:

For n = 10^18 (one quintillion objects), P ~= 8.6 x 10^-42. This is negligible for any practical deployment. Per-file hashes provide an additional layer: an adversary who modifies a file within the payload and also forges the envelope hash faces a birthday collision probability of 2^-128 for each file, compounded across all files in the manifest.

Confidentiality This document does not define encryption of the payload. Implementations handling sensitive data MUST use transport-layer security (TLS 1.3 or later) when transmitting SNAP Objects. At-rest encryption of the payload field is RECOMMENDED for sensitive backups and is out of scope for this specification.

Replay and Freshness The "id" field (UUID v4) and "created" timestamp provide replay detection at the application layer. Receivers SHOULD record recently accepted IDs to detect duplicate submissions.

Denial of Service A Decoder MUST enforce upper bounds on the size of the JSON document and the decompressed payload before processing, to prevent compression bombs. A RECOMMENDED limit is 10 GiB for the decompressed payload.

IANA Considerations

YANG Module Registration This document requests registration of the following YANG module in the "YANG Module Names" registry : Field Value Name snap Namespace urn:ietf:params:xml:ns:yang:snap Prefix snap Reference This document

Media Type Registration This document requests registration of the media type "application/snap+json" in the "Media Types" registry:

Type name:

application

Subtype name:

snap+json

Required parameters:

None

Optional parameters:

None

Encoding considerations:

Binary (Base64-encoded content within a JSON document)

Security considerations:

See Section 7 of this document

Interoperability considerations:

None

Published specification:

This document

Applications that use this media type:

Backup systems, configuration management systems, network management systems

Fragment identifier considerations:

None

Additional information:

None

Person and email address to contact for further information:

See Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

None

Author:

See Authors' Addresses section

Change controller:

IETF

URI Namespace Registration This document requests registration of the following entry in the "ns" registry within the "IETF XML Registry": URI Registrant XML urn:ietf:params:xml:ns:yang:snap IANA This document

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. National Institute of Standards and Technology In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK] Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME. Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document replaces and obsoletes RFC 8478. There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata. Telefonica Telefonica INSA-Lyon Telefonica Fraunhofer SIT UC3M This document defines a mechanism based on COSE signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data stream is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. Cisco Systems, Inc. Equinix Cisco Systems, Inc. Nokia This document defines YANG packages; a versioned organizational structure used to manage schema and conformance of YANG modules as a cohesive set instead of individually. I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

Mathematical Proofs of Design Decisions This appendix provides formal mathematical justification for each major design decision in SNAP. Each theorem is stated, proven, and labeled with QED.

Theorem A.1: Compression Lower Bound (Shannon, 1948) Statement. No lossless code can compress a source X below its entropy H(X), and Brotli achieves the closest practical bound among IETF-standardized codecs for structured text. Proof. By Shannon's source coding theorem , for any discrete source X with probability distribution p(x):

= H(X) [for any lossless code] ]]>

For structured text (configuration files, YANG/JSON), empirical entropy is H ~= 3.5-5.0 bits/byte, giving an optimal ratio r_optimal ~= 0.44-0.625. Brotli measured ratios fall in 0.72-0.78 (within 2-5% of the entropy limit and 15-25% better than gzip ). No alternative IETF codec achieves a tighter bound for this class. Therefore Brotli is the RECOMMENDED algorithm. QED.

Theorem A.2: SHA-256 Collision Resistance Statement. For any practical SNAP deployment of n <= 10^18 objects, the probability of an envelope-hash collision is below 10^-41. Proof. SHA-256 maps {0,1}* -> {0,1}^256, giving 2^256 possible digests. By the birthday paradox, the probability of any collision in n samples is:

Substituting n = 10^18:

This is many orders of magnitude below any hardware error rate (~10^-^6 per hour) over the same timescale. Therefore SHA-256 envelope hashing is collision-resistant for all practical SNAP deployments. QED.

Theorem A.3: Base64+Brotli Overhead is Approximately Unity Statement. For typical structured text, the SNAP payload field is no larger than the original uncompressed input. Proof. Base64 expands every 3 input bytes to 4 output characters, an exact overhead factor 4/3 = 1.333... . Brotli on configuration text achieves r_br ~= 0.75. Composing:

For highly repetitive data, r_br ~= 0.55 gives:

In both cases, S_payload <= S_original. QED.

Theorem A.4: Minimum Round-Trip Transport Time Statement. SNAP achieves the theoretical minimum transport time for reliable ordered delivery over a single TCP-class connection. Proof. For any reliable, ordered transport with bandwidth B and round-trip time RTT, the time to deliver |S| bytes atomically is bounded below by:

SNAP transmits the entire object in one HTTP POST body (Section 5.1), thus:

Any protocol requiring k >= 1 additional rounds for negotiation, delta exchange, or index transfer satisfies:

= T_SNAP + k x RTT ]]>

Therefore SNAP is optimal in transport time. QED.

Theorem A.5: Manifest Verification Complexity Statement. SNAP's flat manifest matches Merkle-tree complexity for full-backup verification and beats it for single-file verification. Proof. Let n be the number of files. By inspection of Section 4.2: Operation SNAP Manifest Merkle Tree Full backup verify O(n) hashes O(n) hashes Single-file verify O(1) lookup O(log n) hashes Manifest storage O(32n) bytes O(32n) bytes Construction cost O(n) operations O(n) operations For full verification both structures are O(n). For single-file verification SNAP performs one hash equality check; a Merkle tree requires log_2(n) sibling-hash comparisons. Therefore SNAP is asymptotically optimal for both cases. QED.

Theorem A.6: Round-Trip Correctness Statement. For any valid file set F and metadata M: decode(encode(F, M)) = (F, M). Proof. Let O = encode(F, M). By Section 4.1: The manifest contains an entry (path_i, sha256_i, size_i, mtime_i) for each f_i in F, with sha256_i = SHA256(f_i). The payload contains the USTAR-tar of all f_i in lexicographic order, compressed and Base64-encoded. meta.hash = SHA256(JCS(O \ {meta.hash})). By Section 4.2, decode(O): Validates O against the YANG schema (success by Section 4.1 step 6). Recomputes envelope hash; equals meta.hash by Section 4.1 step 8 and Lemma 3 of Section 3.5 (JCS uniqueness). Base64-decodes and decompresses the payload yielding the original tar bytes. Extracts each f_i and verifies SHA256(f_i) = sha256_i (success by Section 4.1 step 2 and SHA-256 determinism). Writes each f_i to disk with mtime_i. The output is exactly (F, M). QED.

Reference Pseudocode This appendix provides language-agnostic pseudocode for the SNAP encode and decode procedures. It is non-normative; the normative specification is in Section 4.

Encode

Decode

Verify Without Restore

Test Vectors This appendix provides reproducible test vectors that all conforming implementations MUST be able to verify.

Vector 1: Empty Backup A backup containing zero files, with fixed id and timestamp:

The exact envelope hash is computed deterministically by any conforming Encoder applied to these inputs.

Vector 2: Single-File Backup A backup containing one file "hello.txt" with content "Hello, SNAP!\n":

", "size": 13, "mtime": "2026-01-01T11:00:00Z" } ] Note: The literal SHA-256 of "Hello, SNAP!\n" is computed by any SHA-256 implementation; this document does not pre-compute it here to avoid mistakes -- implementers MUST verify against their local SHA-256. The reference repository (front matter) publishes the exact expected values as JSON fixtures. ]]>

Vector 3: JCS Round-Trip For the minimal SNAP envelope:

The JCS output MUST sort keys alphabetically at every level. The expected canonical form begins:

(The "" line continuations above are for display in this document only; the actual canonical form is a single line with no line breaks.) Any Encoder whose JCS output does not match this byte-for-byte is non-conforming.

Vector 4: Tamper Detection Take the Vector 2 output and modify a single byte of the payload (e.g., flip the high bit of the first byte). Recompute meta.hash without re-encoding the rest of the document -- i.e., produce an inconsistent object. Any conforming Decoder MUST reject this object during step 3 of Section 4.2 (envelope hash mismatch).

Vector 5: MVPS Bundle Round-Trip This vector exercises Theorem M.1 (). Inputs:

, mtime: "2026-01-01T00:00:00Z" } ] enc = "br" ]]>

Conformance procedure: Encode the MVPS Bundle into a SNAP Object O. Compute the MVPS coherence vector C(t) and the scalar H on the pre-SNAP bundle (using the reference implementation referenced in ). snap_decode(O) to recover bundle.json. Recompute C(t) and H on the recovered bundle. Assert: pre-SNAP C(t) == post-SNAP C(t), bit-for-bit. Assert: pre-SNAP H == post-SNAP H, bit-for-bit. Assert: pre-SNAP bundle bytes == post-SNAP bundle bytes. A conforming SNAP implementation MUST pass all three assertions. This vector is the direct empirical witness for Theorem M.1.

Conformance Procedure A vendor implementation is conformance-tested by: Running the Encoder against Vectors 1-2 with fixed inputs and comparing the byte-exact JCS output and envelope hash. Running the Decoder against the published fixture objects and verifying that all four vectors produce the expected result (accept Vector 1-3, reject Vector 4). Publishing the result to the SNAP interoperability matrix.

SNAP x MVPS Composition Theorems This appendix establishes that SNAP composes with the MVPS family as an atomic transport substrate without altering any of the MVPS guarantees. Four composition theorems are proved. Each is testable against the validator scripts referenced in .

D.1 Theorem M.1 (Bundle Preservation) Statement. Let B be a valid MVPS Bundle conforming to . Let O = snap_encode({B}, M) be the SNAP Object that wraps B as its sole payload file. Let B' = snap_decode(O) be the restored bundle. Then B' = B byte-for-byte and every MVPS coherence axis (C_1, C_2, C_3) and the scalar H computed on B' equals the value computed on B. Proof. By Theorem A.6 (Round-Trip Correctness), the SNAP decode of an SNAP encode yields the original file set; in particular the single file containing B is restored byte-identically. Since C_1, C_2, C_3 and H are pure functions of the bundle bytes (definitions in D1, D3, F1-F4, I1), they are invariant under any byte-preserving transport. Therefore the coherence axes and H computed downstream of SNAP transport are identical to those computed on B at the source. QED. Corollary M.1.1. Theorem 1 of (boundedness H in [0, H_max]) is preserved through SNAP transport. Corollary M.1.2. Theorems 2 and 3' of (FAR calibration via Mahalanobis D^2) are preserved through SNAP transport, including the operational contract OC3 (n_calib >= 18,500 for +/-1% FAR precision).

D.2 Theorem M.2 (Architectural Conformance) Statement. A SNAP-based backup system that carries MVPS Bundles between N >= 3 vantages and a broker satisfies the MVPS Architecture axioms A1..A5 of , hence inherits the Invariance Theorem and therefore Theorems 1, 2, 3, 3', 4, 5, 9 and Stein's Lemma verbatim. Proof. The axioms A1..A5 require: A1 (Vantage independence): each SNAP-encoded bundle originates from one vantage; the SNAP id (UUID v4) provides a globally unique per-bundle identifier per RFC 4122. A2 (Bounded simplex on C in [0,1]^3): preserved by Theorem M.1 (byte-identical transport). A3 (Coordinated time window): the MVPS coordination_window is carried as JSON inside the SNAP payload; per Theorem A.6 it is restored exactly. A4 (Independent observers, basis for Stein's Lemma): the SNAP transport adds no cross-vantage coupling because each SNAP Object is an atomic, independent unit (Section 4.1 step 9). A5 (Falsifiable publication): the SNAP envelope hash (meta.hash) is a publicly verifiable commitment to the carried bundle; any receiver can recompute it and reject tampering (Section 4.2 step 3). Therefore A1..A5 hold, and by the Invariance Theorem of the inherited MVPS theorems hold. QED.

D.3 Theorem M.3 (Byzantine-Resilient Backup) Statement. Suppose N >= 3 vantages each encode their MVPS Bundle as a SNAP Object and submit it to a broker. Suppose at most f vantages are Byzantine (arbitrarily faulty or adversarial). If the broker computes the geometric-median centroid of the per-vantage coherence vectors recovered from the SNAP Objects, then the max-bias on the centroid is bounded by:

provided N > 2f. Proof. Theorem M.1 ensures that the broker recovers each vantage's bundle exactly; therefore the post-SNAP coherence vectors are identical to the pre-SNAP coherence vectors. Theorem 9 of then applies verbatim: the geometric-median centroid on N vectors with at most f corrupted is bounded by the stated inequality (I12 = Minsker; Cohen et al.). SNAP introduces no additional attack surface because: Each SNAP envelope hash is collision-resistant by Theorem A.2 (P(collision) ~= 8.6 x 10^-42 for n = 10^18 objects); Per-file SHA-256 manifest entries detect any modification of B in transit by an active attacker who cannot also forge the envelope hash (compound bound 2^-128 per file). Therefore SNAP preserves the f-resilience floor of MVPS. QED. Corollary M.3.1. The MVPS DDoS Resilience Profile (D-4) bound of floor((k-1)/2) simultaneous regional attacks is preserved when the SNAP transport is used for D-4 telemetry bundles.

D.4 Theorem M.4 (Planetary Floor for SNAP Backup) Statement. Let S be a SNAP Object of compressed size |S| bytes transported over a path with one-way light-time tau_light and bandwidth B. Then the SNAP backup achieves the MVPS planetary coherence floor R* for backup, satisfying:

where R* is the planetary floor defined in . Proof. SNAP delivers atomically in one round-trip (Theorem A.4), so the only non-causal component of its latency is wire time |S|/B. Special relativity establishes 2 tau_light as the lower bound on RTT (T-1 of D-7 in ). By the definition of R* (PCF),

= tau_causal = 2 tau_light (antipodal) ]]>

so tau_snap_backup <= R* + |S| / B. Therefore SNAP saturates the tau_causal component of R* with zero protocol overhead, and adds only wire time. In particular, for |S| << R* * B, SNAP backup is tau_causal-bound. For Earth-antipodal paths (R* ~= 145-196 ms per ) and |S| <= 14,600 bytes (single TCP initial congestion window), SNAP transport completes within the planetary floor without bandwidth slack. QED. Corollary M.4.1. Classical multi-phase backup protocols (rsync >= 3 RTT, BorgBackup repository handshake) violate the tau_causal floor by a factor of k >= 2 (Theorem A.4); SNAP does not.

D.5 Operational Contracts Inherited from MVPS A SNAP implementation carrying MVPS data MUST honor the following operational contracts from : OC1 (N >= 3): At least three independent vantage SNAP Objects are REQUIRED for geometric-median centroid computation downstream. OC2 (Sampling cadence G >= W_max): SNAP delivery cadence MUST NOT exceed the MVPS cadence guarantee; otherwise sub-sampling violates the iid input assumption of the Mahalanobis statistic. OC3 (n_calib >= 18,500): A SNAP-based backup of FAR-calibration data MUST preserve a minimum of 18,500 calibration samples for +/-1% FAR precision. OC4 (rank(Sigma) = 3): The bundle carried by SNAP MUST be structurally complete; SNAP MUST NOT partition the bundle into separate objects because that would destroy the full-rank covariance. OC8 (Thresholds in [exp(-1), 1]): SNAP does not alter the MVPS thresholds; preserved trivially by Theorem M.1. The contracts OC5, OC6, OC7 of are downstream concerns of the MVPS analytic engine and are unaffected by the choice of transport.

D.6 SNAP-MVPS Traceability Matrix SNAP Theorem Inherits From Preserves Theorem 1 (Encoder Determinism) RFC 8785 (JCS uniqueness) MVPS bundle byte-identity Theorem A.1 (Shannon bound) Shannon 1948 MVPS payload minimality Theorem A.2 (SHA-256 collision) FIPS 180-4 MVPS envelope integrity Theorem A.4 (Min RTT) Network theory MVPS PCF tau_causal saturation Theorem A.6 (Round-trip correctness) YANG schema closure MVPS coherence preservation Theorem M.1 (Bundle preservation) Theorem A.6 MVPS Theorem 1, OC4 Theorem M.2 (Architectural conformance) MVPS axioms A1..A5 MVPS Invariance Theorem Theorem M.3 (Byzantine resilience) MVPS Theorem 9 MVPS f/N max-bias floor Theorem M.4 (PCF backup) MVPS PCF D-15 tau_causal saturation Every SNAP claim therefore has a finite chase either to an IETF RFC, to , or to a foundational result (Shannon, Merkle, Stein, FIPS). No SNAP property is promoted to a theorem without proof; all empirical observations are explicitly tagged as conjectures in the same discipline as .

Contributors The following person contributed substantially to this document but is not listed as an author for IETF stream-management considerations (RFC 7322, Section 4.1.1):

Leonardo Melegassi originated the SNAP design, authored the initial wire-format specification, the YANG module, the mathematical proof corpus (Appendix A), and the MVPS composition theorems (Appendix D). He also authored the broader MVPS family of drafts (D-1, D-2, D-3, D-4, D-5, D-6, D-7, D-15, D-16) for which SNAP serves as the atomic transport substrate.

Acknowledgments The authors thank the IETF DISPATCH, NETMOD, IPPM, BFD, and OPSAWG working groups for their foundational work on YANG data modeling, JSON encoding, and multi-vantage path measurement. The mathematical foundations of this work rest on the contributions of Claude Shannon (1948), Ralph Merkle (1979), Charles Stein (1952), and the MVPS v4.0 proof catalogue . This document is the eleventh joint draft of the MVPS family (D-1, D-2, D-3, D-4, D-5, D-6, D-7, D-15, D-16, plus the SNAP substrate defined here) and the first to standardize the atomic transport unit on which the rest of the family operationally depends. All composition theorems in are validated against the same 44/44 attack-defense suite that disciplines . The author team for this document brings together five independent organizations spanning network operations (e.Mix, Vero Internet), infrastructure integration (Sysbrasil Tecnologia), cloud storage (Zadara), and consulting (OrcaTI). This multi-vendor authorship is itself a deliberate operational anchor for the document: by construction, the SNAP format MUST be implementable by all five author organizations in their existing technology stacks, ensuring that no single-vendor design bias contaminates the specification. The authors also gratefully acknowledge Leonardo Melegassi (Catellix), listed in the Contributors section, who originated the SNAP design as the atomic transport substrate for the MVPS family of drafts and contributed the initial specification, the YANG module, and the mathematical proof corpus on which this document is built.

Change Log

Version -01 Editorial only. No technical changes to the SNAP wire format, the YANG module, or any theorem/proof. Replaced all non-ASCII characters in the running text with ASCII equivalents (for example, "<=" for U+2264, "Section " for U+00A7, "--" for U+2014, "^2" for U+00B2, "x" for U+00D7, "_i" for U+1D62), so that the document passes "idnits 2.17.1" cleanly under the strict ASCII-only checklist. All mathematical formulas and section references retain their semantic meaning. Reorganised the author list to five authors with a separate Contributors section, per RFC 7322 Section 4.1.1 guidance on excessive author counts. Bumped document version to -01.

Version -00 Initial version. Cancelled and republished as -01.