Network Working Group S. S. Cummings Internet-Draft E2 LLC Intended status: Informational 20 October 2026 Expires: 23 April 2027 HyPR: Hybrid Parity for Remote Resilience draft-cummings-hypr-00 Abstract Local redundancy mechanisms such as RAID and software-defined parity pools tolerate only a bounded number of correlated device losses, while remote backup services typically require replication of the full data set. HyPR's remote storage requirement scales with the parity-to-data ratio m/k rather than with the size of the protected data, at the cost of not protecting against total loss of the local copy. This document specifies HyPR (Hybrid Parity for Remote Resilience), a framework that treats remote storage, including consumer-grade end-to-end-encrypted cloud services, as additional failure-domain participants in an erasure-coded storage system. HyPR defines a content-chunked Remote Parity Fragment format, transport requirements for backend-agnostic encrypted fragment delivery, immutable and versioned vault semantics, a resumable reconstruction protocol that produces signed rebuild receipts, and a boundary within which machine-learned orchestration agents may advise but never replace deterministic reconstruction. Note to Readers This note is to be removed before publishing as an RFC. This is an individual submission. It is not the product of an IETF working group, and it does not represent IETF consensus. Comments may be sent to the author at the address above. 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/. Cummings Expires 23 April 2027 [Page 1] Internet-Draft HyPR October 2026 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 23 April 2027. 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 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Chunking and Supplemental Erasure Coding . . . . . . . . . . 6 5.1. Content-Defined Chunking . . . . . . . . . . . . . . . . 6 5.2. Supplemental Stripes . . . . . . . . . . . . . . . . . . 7 5.3. Immutability of Stripes and Incremental Updates . . . . . 7 5.4. Protection Envelope . . . . . . . . . . . . . . . . . . . 8 5.5. Remote Storage Overhead . . . . . . . . . . . . . . . . . 8 5.6. Rateless Extension . . . . . . . . . . . . . . . . . . . 10 6. Remote Parity Fragment Format . . . . . . . . . . . . . . . . 11 7. Vault Manifest . . . . . . . . . . . . . . . . . . . . . . . 13 8. Transport Requirements . . . . . . . . . . . . . . . . . . . 13 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . 14 10. Immutable Vault Semantics . . . . . . . . . . . . . . . . . . 15 11. Detecting Degraded Stripes . . . . . . . . . . . . . . . . . 15 12. Reconstruction Protocol . . . . . . . . . . . . . . . . . . . 16 13. Restoring Reconstructed Data . . . . . . . . . . . . . . . . 17 14. Advisory Orchestration . . . . . . . . . . . . . . . . . . . 18 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 16. Security Considerations . . . . . . . . . . . . . . . . . . . 19 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 Cummings Expires 23 April 2027 [Page 2] Internet-Draft HyPR October 2026 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 18.1. Normative References . . . . . . . . . . . . . . . . . . 20 18.2. Informative References . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Redundant arrays and erasure codes tolerate loss only within the failure domains they span. A RAID-Z3 array survives three drive failures, but it does not survive a controller fault that removes several drives at once, a firmware or manufacturing-batch failure that affects a whole cohort of drives, or the loss of the site that houses the array. Remote replication addresses site loss, but it carries at least 100% storage overhead and exposes plaintext to the provider unless the data is separately encrypted. No standardized protocol currently allows a client to compute supplemental erasure-coded parity for data held on an existing local array and deposit that parity on arbitrary remote storage, so that losses exceeding the local redundancy budget can be repaired using only a fractional amount of remote capacity. This document describes such a framework, called HyPR. HyPR does not propose a new file system and does not modify the local array. It operates above the storage mechanism layer, on content- defined chunks of file data, and computes Remote Parity Fragments that are encrypted on the client and delivered to any conforming remote store. HyPR is complementary to, and not a replacement for, a full offsite copy. As shown in Section 5.4, remote parity of fractional size cannot by itself restore a data set whose local copy has been lost entirely. HyPR addresses losses that are partial, correlated, or beyond the local redundancy budget. 1.1. Scope and Non-Goals This document specifies the Remote Parity Fragment format (Section 6), the vault manifest (Section 7), transport and vault requirements (Section 8, Section 9, Section 10), degraded-stripe detection and restoration (Section 11, Section 13), the reconstruction protocol (Section 12), and the boundary between deterministic reconstruction and advisory orchestration (Section 14). This document does not specify a file system, a replacement for local RAID, a cloud provider API, a key escrow service, or the internal behavior of any machine-learned model. Cummings Expires 23 April 2027 [Page 3] Internet-Draft HyPR October 2026 1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology Local Array A set of storage devices under a common electrical, administrative, and spatial failure domain, for example a ZFS pool, a Btrfs volume, or an mdadm array. Failure Domain Any grouping of storage elements subject to correlated failure, including power, controller, firmware cohort, manufacturing batch, and physical location. Chunk A variable-length unit of file data produced by content-defined chunking (Section 5.1). Stripe Unit A fixed-size block of data formed from one Chunk, or from a padded or concatenated group of Chunks, that serves as an input symbol to the supplemental erasure code. Supplemental Stripe A logical stripe consisting of k Stripe Units and the m Remote Parity Fragments computed over them. Remote Parity Fragment (RPF) An erasure-coded parity fragment, computed and encrypted on the client, that holds no independently intelligible data and is deposited on remote storage. Vault A remote, append-only, versioned store of RPFs and manifests with the immutability properties of Section 10. Epoch A monotonically increasing identifier for a consistent point-in- time state of a Vault. Cummings Expires 23 April 2027 [Page 4] Internet-Draft HyPR October 2026 Manifest An encrypted, versioned record stored in the Vault that describes Supplemental Stripe membership, code parameters, and fragment locations for an Epoch. HyPR Core The deterministic userspace component that performs chunking, encoding, encryption, transport, and reconstruction. Orchestration Agent An optional local component that provides advisory failure prediction, repair prioritization, and tiering suggestions. An Orchestration Agent does not participate in reconstruction arithmetic (Section 14). Rebuild Receipt A signed record emitted by the HyPR Core after a reconstruction (Section 12). 3. Problem Statement Existing approaches fall short along three axes. 1. Domain binding. Standard local erasure codes, such as mdadm RAID levels, ZFS RAID-Z, and Btrfs profiles, cannot extend parity across a wide-area boundary. Their redundancy is bounded by the devices in the local array, and a single correlated event can exceed it. 2. Asymmetry. Remote backup replicates data, which carries 100% or greater storage overhead and, absent separate encryption, exposes content to the provider. Parity fragments carry no independently intelligible payload and incur only fractional overhead. 3. Reconstruction coupling. No widely deployed remote-backup mechanism defines how a degraded local array identifies which parity it requires, so that a targeted partial rebuild can be performed instead of a full restore. Related mechanisms exist but address different problems. File parity tools such as PAR2 [PAR2] and SnapRAID compute parity over files or disk sets, typically stored locally and without a defined remote delivery or immutability model. Distributed filesystems such as Tahoe-LAFS [TAHOE] erasure-code and encrypt the data itself across servers, rather than adding supplemental parity to an existing local array. Deduplicating backup tools such as restic and Borg use content-defined chunking and encrypted repositories but replicate chunks rather than computing cross-chunk parity. Cummings Expires 23 April 2027 [Page 5] Internet-Draft HyPR October 2026 4. Architecture +-------------------------------------------------------------+ | Orchestration Agent (optional, advisory) | | failure prediction / tiering / repair scheduling | +------------------------------+------------------------------+ | advice only +------------------------------v------------------------------+ | HyPR Core (deterministic) | | chunking | supplemental EC | encryption | keys | rebuild | +---------------+-----------------------------+---------------+ | | +---------v---------+ +---------v---------+ | Local Array | | Remote Vault(s) | |(ZFS, Btrfs, mdadm;|-RPFs--->| (S3-compatible, | | unmodified) | | SFTP, WebDAV) | +-------------------+ +-------------------+ Figure 1: HyPR Architecture The HyPR Core reads file data from the Local Array, forms Supplemental Stripes, computes RPFs, encrypts them, and delivers them to one or more Vaults together with an encrypted Manifest. The Local Array is not modified and need not be aware of HyPR. The layering is two-tier: the Local Array provides inner redundancy at the device level, and HyPR provides outer redundancy at the Chunk level. 5. Chunking and Supplemental Erasure Coding 5.1. Content-Defined Chunking A HyPR Core MUST divide file data into Chunks using content-defined chunking, for example Rabin fingerprinting [RABIN], such that an insertion or deletion perturbs a bounded number of Chunks. Chunking parameters, including any polynomial or seed, SHOULD be secret to the Vault owner and derived from the Vault key material. Public, fixed chunking parameters allow an observer of fragment sizes and boundaries to confirm the presence of known content (Section 16). Minimum, average, and maximum Chunk sizes are deployment-configurable and are recorded in the Manifest. Cummings Expires 23 April 2027 [Page 6] Internet-Draft HyPR October 2026 5.2. Supplemental Stripes The HyPR Core groups Stripe Units into Supplemental Stripes of k units and computes m RPFs over each stripe using a systematic maximum-distance-separable (MDS) code, for example Reed-Solomon over GF(2^8) or GF(2^16) [REEDSOLOMON] [PLANK]. Any k of the k+m members of a Supplemental Stripe suffice to recover all k Stripe Units. When GF(2^8) is used, k+m MUST NOT exceed 256. The Supplemental Stripe is a logical construct defined by HyPR over Chunks. It does not depend on the physical stripe geometry or the parity of the Local Array, which HyPR treats as opaque. Because HyPR cannot observe where the Local Array places data, stripe membership SHOULD be formed by interleaving Chunks drawn from files written at different times and from different parts of the file tree. This reduces the likelihood that a localized failure in the Local Array erases more than m members of any one Supplemental Stripe. The protection this provides against physical loss is therefore statistical rather than guaranteed. As an illustration only, assume that Stripe Units are placed uniformly and independently across the Local Array, and that a fraction f of local data becomes unreadable while the m RPFs of each stripe remain intact. A stripe is then unrecoverable when more than m of its k local Stripe Units are lost, which has probability P(X > m) for X distributed Binomial(k, f). For k = 10, m = 2, and f = 1%, this is about 1.1 x 10^-4 per stripe. With 1 MiB Stripe Units, a 50 TB data set has roughly 4.8 million such stripes, so about 540 stripes would be unrecoverable. The model shows that HyPR is most effective against small, scattered losses and that its benefit falls quickly as the lost fraction rises. It is not a guarantee, because real placement is neither uniform nor independent. 5.3. Immutability of Stripes and Incremental Updates A Supplemental Stripe is immutable once sealed, and a Vault object is never modified in place. When file data changes, the HyPR Core forms new Stripe Units, new Supplemental Stripes, and new RPFs in a new Epoch. Stripes that no longer reference live data are released by retention policy (Section 10) and not by overwrite. Because RPFs are encrypted on the client, a remote party cannot apply parity deltas. The client computes each new RPF in full and uploads it as a new object. Remote write amplification is bounded by the number of Supplemental Stripes touched by changed Chunks, not by the size of the data set. Implementations MAY use the linearity of the code to compute an updated RPF from the old and new Stripe Units, Cummings Expires 23 April 2027 [Page 7] Internet-Draft HyPR October 2026 where each parity row is combined using the appropriate field coefficient, but this is a local optimization and is not visible to the Vault. 5.4. Protection Envelope For a Supplemental Stripe of k Stripe Units and m RPFs, the stripe remains recoverable after the loss or corruption of any m or fewer of its k+m members, where RPFs held on remote storage count as members. Recovering a data set of size D requires at least D units of information to survive. Consequently, if every local copy of the k Stripe Units is lost and only m < k RPFs remain, the stripe cannot be recovered. HyPR therefore protects against: * device or controller failures that exhaust the local redundancy budget while leaving a majority of each stripe's Stripe Units readable; * correlated failures of a drive cohort, within the statistical limits of Section 5.2; * latent unreadable sectors and silent corruption that surface during a degraded rebuild of the Local Array; * destructive modification or encryption of a subset of local data by malware, provided the affected fraction of each stripe does not exceed m. HyPR does not, by itself, protect against the simultaneous loss of all or most local data, such as loss of the entire site. Deployments that require that property MUST maintain a full offsite copy, and MAY use HyPR in addition to it. A deployment that sets m greater than or equal to k obtains full-copy recoverability from parity alone, at storage overhead comparable to replication. 5.5. Remote Storage Overhead A principal advantage of HyPR over full offsite replication is reduced remote storage. For a Supplemental Stripe of k Stripe Units and m RPFs, the remote parity occupies m/k of the protected data size, whereas a full offsite copy occupies 100% of it. Table 1 gives examples for a 50 TB data set. Cummings Expires 23 April 2027 [Page 8] Internet-Draft HyPR October 2026 +==============+=================+================+================+ | Scheme | Remote overhead | Remote storage | Survives total | | | | | local loss | +==============+=================+================+================+ | Full offsite | 100% | 50 TB | Yes | | copy | | | | +--------------+-----------------+----------------+----------------+ | HyPR, k=4, | 50% | 25 TB | No | | m=2 | | | | +--------------+-----------------+----------------+----------------+ | HyPR, k=10, | 20% | 10 TB | No | | m=2 | | | | +--------------+-----------------+----------------+----------------+ | HyPR, k=20, | 10% | 5 TB | No | | m=2 | | | | +--------------+-----------------+----------------+----------------+ Table 1: Remote Storage for a 50 TB Data Set The figures in Table 1 are the steady-state parity size only. This saving is obtained in exchange for the limitation stated in Section 5.4: remote parity of fractional size cannot restore a data set whose local copy has been lost entirely. HyPR is therefore a means of obtaining protection against losses that exceed the local redundancy budget at a fraction of the remote cost of replication. It is not a substitute for a full offsite copy where total site loss must be survived. The following factors increase actual remote usage above the figures in Table 1. * Immutability and retention (Section 10): changed data produces new Supplemental Stripes in a new Epoch (Section 5.3), and superseded stripes remain until their retention period expires. Remote usage therefore grows with the rate of data change multiplied by the retention period. * Padding and framing: a fixed Fragment Length (Section 15) pads small Chunks, and each RPF carries a 72-octet header and an authentication tag (Section 6). Manifests (Section 7) add further storage. These costs are small for large files and more significant for data sets of many small files. * Upload volume: because RPFs are encrypted on the client, an updated RPF is uploaded in full and not as a delta (Section 5.3). Cummings Expires 23 April 2027 [Page 9] Internet-Draft HyPR October 2026 Under a simplified model, remote usage is approximately (m/k) x D x (1 + c x R), where D is the protected data size, c is the fraction of data that changes per day, and R is the retention period in days. The model assumes that changed data forms new stripes and that superseded stripes are kept for the full retention period. Table 2 applies it to the 50 TB data set with k = 10 and m = 2, and compares it with a full offsite copy kept under the same retention, whose usage is approximately D x (1 + c x R) under the same assumptions. +==================+===============+===================+===========+ | Daily change (c) | Retention (R) | HyPR remote usage | Versioned | | | | | full copy | +==================+===============+===================+===========+ | 0% | any | 10 TB | 50 TB | +------------------+---------------+-------------------+-----------+ | 0.5% | 30 days | 11.5 TB | 57.5 TB | +------------------+---------------+-------------------+-----------+ | 0.5% | 90 days | 14.5 TB | 72.5 TB | +------------------+---------------+-------------------+-----------+ | 2% | 30 days | 16 TB | 80 TB | +------------------+---------------+-------------------+-----------+ | 2% | 90 days | 28 TB | 140 TB | +------------------+---------------+-------------------+-----------+ Table 2: Remote Usage under Churn and Retention (50 TB, k=10, m=2) The ratio between the two right-hand columns stays at m/k, so the relative saving is unchanged by churn, but absolute usage can grow to a multiple of the steady-state parity size. Deployments with high churn and long retention should size remote capacity with this model and not from Table 1 alone. Compared with adding parity devices to the Local Array, HyPR does not reduce the amount of parity stored. It places that parity in a separate failure domain, which is its purpose. 5.6. Rateless Extension Implementations MAY use rateless erasure codes such as RaptorQ [RFC6330] where the number of surviving fragments is uncertain. Rateless reconstruction is best suited to immutable or rarely mutating data, which is consistent with the immutability of Section 5.3. Cummings Expires 23 April 2027 [Page 10] Internet-Draft HyPR October 2026 6. Remote Parity Fragment Format An RPF is a binary object with the layout in Figure 2. All multi- octet integers are in network byte order. The fixed header is 72 octets and is authenticated, but not encrypted, as associated data of the AEAD construction (Section 8). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic (0x48795052) | +---------------+---------------+-------------------------------+ | Version | Code ID | Flags (zero) | +---------------+---------------+-------------------------------+ | | | Vault ID (16 octets) | | | | | +---------------------------------------------------------------+ | | | Stripe ID (16 octets) | | | | | +---------------------------------------------------------------+ | Epoch (8 octets) | | | +-------------------------------+-------------------------------+ | Fragment Index | K | +-------------------------------+-------------------------------+ | M | Key Generation | +-------------------------------+-------------------------------+ | Fragment Length | +---------------------------------------------------------------+ | | | Nonce (12 octets) | | | +---------------------------------------------------------------+ | Ciphertext (Fragment Length octets) | +---------------------------------------------------------------+ | | | Authentication Tag (16 octets) | | | | | +---------------------------------------------------------------+ Figure 2: RPF Layout Cummings Expires 23 April 2027 [Page 11] Internet-Draft HyPR October 2026 +============+==========+=========================================+ | Field | Size | Description | | | (octets) | | +============+==========+=========================================+ | Magic | 4 | 0x48 0x79 0x50 0x52 ("HyPR") | +------------+----------+-----------------------------------------+ | Version | 1 | Format version; this document defines | | | | 0x01 | +------------+----------+-----------------------------------------+ | Code ID | 1 | 1 = Reed-Solomon over GF(2^8); 2 = | | | | Reed-Solomon over GF(2^16); 3 = RaptorQ | +------------+----------+-----------------------------------------+ | Flags | 2 | Reserved; MUST be zero on send and | | | | ignored on receipt | +------------+----------+-----------------------------------------+ | Vault ID | 16 | Random identifier of the Vault | +------------+----------+-----------------------------------------+ | Stripe ID | 16 | Random identifier of the Supplemental | | | | Stripe | +------------+----------+-----------------------------------------+ | Epoch | 8 | Epoch in which the RPF was written | +------------+----------+-----------------------------------------+ | Fragment | 2 | Index of this RPF among the m parity | | Index | | fragments, starting at zero | +------------+----------+-----------------------------------------+ | K | 2 | Number of Stripe Units in the stripe | +------------+----------+-----------------------------------------+ | M | 2 | Number of RPFs in the stripe | +------------+----------+-----------------------------------------+ | Key | 2 | Identifier of the master key generation | | Generation | | from which this RPF's key is derived | | | | (Section 9) | +------------+----------+-----------------------------------------+ | Fragment | 4 | Length of the ciphertext in octets | | Length | | | +------------+----------+-----------------------------------------+ | Nonce | 12 | AEAD nonce | +------------+----------+-----------------------------------------+ Table 3: RPF Header Fields Implementations SHOULD use a fixed Fragment Length across a Vault so that fragment sizes do not reveal Chunk sizes (Section 15). The IANA media type for an RPF container is requested in Section 17. Cummings Expires 23 April 2027 [Page 12] Internet-Draft HyPR October 2026 7. Vault Manifest Reconstruction after loss of local state requires knowing which Chunks belong to which Supplemental Stripe and where the corresponding RPFs are stored. The HyPR Core MUST therefore write, for each Epoch, an encrypted Manifest to the Vault. A Manifest records: * the code parameters (Code ID, k, m, Fragment Length); * for each Supplemental Stripe, its Stripe ID and the digest of each member Stripe Unit; * for each Chunk, the file path, the offset and length of the Chunk within that file, and the file's size and modification time at the time the Epoch was sealed, so that reconstructed Chunks can be placed back into files (Section 13); * the Vault object name of each RPF; * the chunking parameters of Section 5.1, as permitted by the key policy; and * the digest of the preceding Epoch's Manifest, forming a hash chain. Digests MUST use SHA-256 [RFC6234] or a stronger function. A Manifest MUST be encrypted with an AEAD construction under a key distinct from the RPF keys. A HyPR Core MUST verify the hash chain when it enumerates Epochs and MUST report any discontinuity to the operator. 8. Transport Requirements A conforming transport MUST provide the following. 1. Client-side encryption before egress. The remote party MUST NOT hold, and MUST NOT be able to derive, any decryption key. RPFs and Manifests MUST be encrypted with an AEAD construction. ChaCha20-Poly1305 [RFC8439] is mandatory to implement. Implementations MUST ensure that a (key, nonce) pair is never reused. Deriving a distinct key for each RPF from the master key, Vault ID, Stripe ID, Fragment Index, and Epoch using HKDF [RFC5869] is RECOMMENDED. 2. Resumable retrieval. The transport MUST support byte-range retrieval of fragments and resumption of an interrupted transfer without restarting completed fragments. Cummings Expires 23 April 2027 [Page 13] Internet-Draft HyPR October 2026 3. Integrity verification. The HyPR Core MUST verify the AEAD tag of every RPF and the digest of every recovered Stripe Unit before using them in reconstruction. Transports SHOULD map onto existing protocols, including S3-compatible object APIs, SFTP, and WebDAV [RFC4918]. A HyPR Core MUST NOT depend on any provider feature other than object creation, ranged read, listing, and, where available, object-level immutability. 9. Key Management This section defines the minimum key management required for interoperable recovery. Key escrow services, hardware token interfaces, and organizational key policy are out of scope. Key hierarchy. A Vault has one master key of at least 256 bits, generated by a cryptographically secure random number generator. Keys for RPF encryption, Manifest encryption, and the chunking secret (Section 5.1) MUST each be derived from the master key using HKDF [RFC5869] with a distinct context label per purpose, so that no two purposes share a key. The Rebuild Receipt signing key (Section 12) is independent of the master key. Key generations. Each master key has a 16-bit Key Generation identifier. It is recorded in the Key Generation field of every RPF header (Section 6) and in the object name of every Manifest, and it is an input to key derivation. Backup and recovery. The master key MUST be backed up to at least one location that is neither the protected host nor the Vault, for example offline media or a hardware token. The recovery procedure MUST be documented and tested. Escrow with a trusted second party is RECOMMENDED where the loss of a single custodian is a realistic risk. Because the Manifest is encrypted, a lost master key means that neither the RPFs nor the Manifest can be read. Rotation. Rotation starts a new Key Generation. New RPFs and Manifests use the new generation, existing objects remain under their original generation, and the HyPR Core MUST retain each old master key for as long as objects protected by it remain in the Vault. Rotation therefore does not retroactively protect existing objects against disclosure of an old key. An operator who needs that protection MUST download, decrypt, re-encrypt under the new generation, and Cummings Expires 23 April 2027 [Page 14] Internet-Draft HyPR October 2026 upload the affected RPFs as new objects, and then allow the old objects to expire under the retention policy. During the transition, remote usage is approximately that of the existing parity set plus the re-encrypted copy. Disclosure. Disclosure of a master key allows an attacker to decrypt the RPFs and the Manifest. The Manifest contains file paths and digests, so the impact includes disclosure of file names and structure and not only of parity. 10. Immutable Vault Semantics A Vault MUST enforce append-only writes with configurable retention, such that compromise of the local system, including malware operating with the local host's credentials, cannot destructively rewrite or delete remote parity within the retention period. To that end: * The credential held by the protected host MUST be limited to creating new objects and reading existing objects. It MUST NOT permit overwrite or deletion. * A credential permitting deletion or retention reduction MUST NOT be stored on the protected host. Such operations MUST require explicit operator action. * Vaults SHOULD expose object-lock or equivalent immutability primitives with a retention period at least as long as the longest interval over which an undetected compromise is considered credible. * Point-in-time Vault states (Epochs) SHOULD be enumerable, permitting restoration to a pre-incident Epoch. Where a provider cannot enforce immutability, the deployment MUST document that limitation, and the HyPR Core SHOULD detect and report unexpected modification or removal of objects at each Epoch. 11. Detecting Degraded Stripes The reconstruction protocol (Section 12) starts from a degraded Supplemental Stripe, that is, one with one or more unreadable or corrupt Stripe Units. Because HyPR treats the Local Array as opaque, it has no direct view of device health, and detection relies on the following sources. Cummings Expires 23 April 2027 [Page 15] Internet-Draft HyPR October 2026 1. Read errors. A read of a Stripe Unit fails with an I/O error, and the unit is treated as missing. 2. Array-reported integrity errors. Checksum errors, scrub results, or degraded-state reports from the Local Array's own integrity mechanism, for example a ZFS or Btrfs scrub. Where the Local Array checksums data, a HyPR Core SHOULD use these reports in preference to hashing all data itself. 3. Verification pass. The HyPR Core reads protected data, recomputes the digest of each Stripe Unit, and compares it with the Manifest. This is the only source that detects silent corruption on a Local Array that does not checksum its own data. 4. Operator request. A verification pass reads every protected byte, so its cost is proportional to the data set size D. For example, a full pass over 50 TB at an aggregate 500 MB/s takes about 28 hours of read time. The HyPR Core therefore MUST make the verification schedule configurable, SHOULD support rate limiting so that production workloads are not starved, and SHOULD support sampled passes that verify a rotating fraction of Stripe Units so that every unit is verified within a bounded number of passes. Encoding needs to read only data that is new or changed since the last Epoch, so a full verification pass is the cost of independent confirmation and not a routine cost of operating HyPR. A Stripe Unit digest in the Manifest is valid only for the data as it was when the Epoch was sealed. A digest mismatch on a file whose size and modification time are unchanged since the Epoch is treated as corruption. A mismatch on a file whose size or modification time has changed is treated as legitimate modification and is not degradation. Such a file is re-encoded in a new Epoch (Section 5.3). A change that preserves file metadata cannot be distinguished from corruption, and treating it as corruption is the safe interpretation. An Orchestration Agent MAY advise on the scheduling and ordering of verification passes. The result of a detection step derives solely from the sources above (Section 14). 12. Reconstruction Protocol When the HyPR Core detects a degraded stripe, that is, a Supplemental Stripe with one or more unreadable or corrupt Stripe Units, it proceeds as follows. Cummings Expires 23 April 2027 [Page 16] Internet-Draft HyPR October 2026 1. It retrieves and verifies the Manifest for the relevant Epoch and identifies the minimal set of RPFs sufficient to reconstruct the missing Stripe Units. It MUST NOT retrieve unnecessary fragments. 2. It opens a resumable, integrity-checked retrieval session with the Vault and fetches only those RPFs. 3. It reconstructs the missing Stripe Units locally and deterministically, and verifies each against the digest in the Manifest. An Orchestration Agent MUST NOT modify reconstructed bytes under any circumstance. 4. It emits a Rebuild Receipt. An interrupted rebuild MUST be resumable without restarting completed fragment transfers. A Rebuild Receipt identifies the Epoch, the reconstructed extents, the source RPFs, and the verification digests, and it is signed with Ed25519 [RFC8032]. The signing key SHOULD be held outside the protected host, for example in a hardware token, so that a compromised host cannot forge a receipt. A receipt records what the HyPR Core did; it does not by itself prove that the reconstructed data is the data originally written. 13. Restoring Reconstructed Data Reconstruction (Section 12) yields verified Stripe Units. This section defines how they are returned to the Local Array. 1. Staging. The HyPR Core MUST first write reconstructed Chunks to a staging location outside the protected data tree, on storage other than the degraded devices where practicable, and MUST verify each against its Manifest digest. The chunk map in the Manifest (Section 7) identifies the file, offset, and length of each Chunk. 2. Assembly. Replacement files are assembled in the staging location from reconstructed Chunks and surviving local Chunks, and are verified Chunk by Chunk. 3. Placement. Replacing or modifying a file in the protected tree is a restoration over existing local data and requires explicit operator authorization (Section 14). When authorized, the HyPR Core MUST write through the ordinary file system interface and MUST NOT write to raw devices, and it SHOULD write under a temporary name followed by an atomic rename where the file system Cummings Expires 23 April 2027 [Page 17] Internet-Draft HyPR October 2026 supports one. HyPR does not repair file system structures. If the file system itself is damaged, the operator restores to a new volume. 4. Degraded array. While the Local Array is itself degraded or resilvering, the HyPR Core SHOULD defer placement until that completes, or restore to a different volume, so that restoration does not add load to, or write into, a failing array. 5. Confirmation. After placement, the HyPR Core re-reads and re- verifies the restored data and emits a receipt addendum, signed in the same way as the Rebuild Receipt, that records the placement. 14. Advisory Orchestration An Orchestration Agent MAY provide advice on: disk failure prediction from time-series device telemetry [PINHEIRO] [SCHROEDER]; degradation-aware repair ordering, which prioritizes stripes approaching their fault-tolerance budget; tiering of data across parity depths on the basis of replaceability; and anomaly detection on synchronization behavior. The following constraints apply. * Orchestration advice is non-binding. The HyPR Core retains authority over, and the ability to refuse, every action. * An Orchestration Agent MUST NOT perform, or supply inputs to, reconstruction arithmetic, and MUST NOT modify any data, Manifest, or RPF. * An Orchestration Agent MUST NOT initiate actions that are destructive or irreversible, including reduction of retention, deletion of RPFs, rotation or destruction of keys, and restoration over existing local data. Those actions require explicit operator authorization. * An Orchestration Agent SHOULD run without access to key material or plaintext file content. * Local inference is RECOMMENDED for privacy-sensitive telemetry. Where remote inference is used, the payload MUST be minimized. * Learned components MUST degrade gracefully to a static schedule if the model is unavailable. Cummings Expires 23 April 2027 [Page 18] Internet-Draft HyPR October 2026 15. Privacy Considerations RPFs are parity, so they carry no independently intelligible payload, and they are encrypted on the client. A remote provider that is compelled to disclose stored objects can disclose only ciphertext, and it cannot recover protected content without keys it does not hold. The provider can still observe access patterns, object counts, object sizes, write timing, and the cleartext header fields of Section 6, which reveal code geometry (K, M), Epoch, and fragment indices. To reduce this surface, deployments SHOULD use a fixed Fragment Length, SHOULD upload on a uniform cadence where practical, and SHOULD use random Vault and Stripe identifiers that carry no semantic content. 16. Security Considerations Key management. Loss of client keys is equivalent to loss of remote protection. Key backup and recovery procedures are REQUIRED to be documented for each deployment. Keys MUST NOT be stored solely within the Vault they protect. Compromised host. A host holding keys and Vault write credentials can write valid- looking but worthless RPFs, and can poison future Epochs. The hash chain and enumerable Epochs of Section 7 and Section 10 allow recovery to a pre-incident Epoch, but only if the compromise is detected within the retention window. Rollback and withholding. Vault immutability is a defense, not a guarantee. A malicious or faulty provider can withhold, delay, or roll back objects. Vault authentication, Manifest hash chaining, and monitoring are complementary controls. Using more than one Vault reduces exposure to a single provider. Chunking side channels. Content-defined chunking with public parameters can allow an observer to confirm that known content is stored. Secret chunking parameters (Section 5.1) and fixed fragment sizes mitigate, but do not eliminate, this channel. Model integrity. The advisory-only constraints of Section 14 bound the effect of a compromised, erroneous, or hallucinating model, because it can neither alter data nor perform irreversible actions. Cummings Expires 23 April 2027 [Page 19] Internet-Draft HyPR October 2026 Correlated local failure. HyPR reduces but cannot eliminate exposure to correlated failure (Section 5.4). Implementation guidance on diversity of drive cohorts and on offsite copies is RECOMMENDED. Code and parameter choice. Weak parameters, such as m = 1 over very large stripes, give little protection against multi-unit loss. Deployments should select k and m in light of measured failure rates. 17. IANA Considerations This document requests registration of the following media type in the standards tree, in accordance with [RFC6838]. Type name: application Subtype name: hypr-rpf Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See Section 16 of this document. Interoperability considerations: See Section 6. Published specification: This document. Applications that use this media type: Backup and storage-resilience software implementing HyPR. Fragment identifier considerations: N/A Additional information: Magic number: the first four octets are 0x48 0x79 0x50 0x52 ("HyPR"). File extension: .rpf. Person and email address to contact for further information: Samuel S. Cummings, samuel@samuelcummings.com Intended usage: COMMON Restrictions on usage: None Author: Samuel S. Cummings Change controller: Author, pending any future working group. This document also requests that IANA create a registry for the RPF Code ID field (Table 3), with initial values 1, 2, and 3 as defined above and a registration policy of Specification Required. 18. References 18.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, . Cummings Expires 23 April 2027 [Page 20] Internet-Draft HyPR October 2026 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . 18.2. Informative References [PAR2] Clements, P. and M. Nahas, "Parity Volume Set Specification 2.0", 2003, . [PINHEIRO] Pinheiro, E., Weber, W.-D., and L. A. Barroso, "Failure Trends in a Large Disk Drive Population", Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST), February 2007. [PLANK] Plank, J. S., "A Tutorial on Reed-Solomon Coding for Fault-Tolerance in RAID-like Systems", Software: Practice and Experience, vol. 27, no. 9, pp. 995-1012, September 1997. [RABIN] Rabin, M. O., "Fingerprinting by Random Polynomials", Harvard University Center for Research in Computing Technology, Technical Report TR-15-81, 1981. Cummings Expires 23 April 2027 [Page 21] Internet-Draft HyPR October 2026 [REEDSOLOMON] Reed, I. S. and G. Solomon, "Polynomial Codes over Certain Finite Fields", Journal of the Society for Industrial and Applied Mathematics, vol. 8, no. 2, pp. 300-304, 1960. [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, . [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, DOI 10.17487/RFC6330, August 2011, . [SCHROEDER] Schroeder, B. and G. A. Gibson, "Disk Failures in the Real World: What Does an MTTF of 1,000,000 Hours Mean to You?", Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST), February 2007. [TAHOE] Wilcox-O'Hearn, Z. and B. Warner, "Tahoe: The Least- Authority Filesystem", Proceedings of the 4th ACM International Workshop on Storage Security and Survivability (StorageSS), 2008. Author's Address Samuel S. Cummings E2 LLC Livonia, Michigan United States of America Email: samuel@samuelcummings.com Cummings Expires 23 April 2027 [Page 22]