HyPR: Hybrid Parity for Remote Resilience

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 , 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.

Scope and Non-Goals This document specifies the Remote Parity Fragment format (), the vault manifest (), transport and vault requirements (, , ), degraded-stripe detection and restoration (, ), the reconstruction protocol (), and the boundary between deterministic reconstruction and advisory orchestration (). 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.

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

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 ().
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 .
Epoch: A monotonically increasing identifier for a consistent point-in-time state of a Vault.
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 ().
Rebuild Receipt: A signed record emitted by the HyPR Core after a reconstruction ().

Problem Statement Existing approaches fall short along three axes.

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.
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.
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 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 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.

Architecture

HyPR Architecture | (S3-compatible, | | unmodified) | | SFTP, WebDAV) | +-------------------+ +-------------------+ ]]> 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.

Chunking and Supplemental Erasure Coding

Content-Defined Chunking A HyPR Core MUST divide file data into Chunks using content-defined chunking, for example Rabin fingerprinting , 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 (). Minimum, average, and maximum Chunk sizes are deployment-configurable and are recorded in the Manifest.

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) . 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.

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 () 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, where each parity row is combined using the appropriate field coefficient, but this is a local optimization and is not visible to the Vault.

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 ;
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.

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. gives examples for a 50 TB data set. Remote Storage for a 50 TB Data Set

Scheme	Remote overhead	Remote storage	Survives total local loss
Full offsite copy	100%	50 TB	Yes
HyPR, k=4, m=2	50%	25 TB	No
HyPR, k=10, m=2	20%	10 TB	No
HyPR, k=20, m=2	10%	5 TB	No

The figures in are the steady-state parity size only. This saving is obtained in exchange for the limitation stated in : 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 .

Immutability and retention (): changed data produces new Supplemental Stripes in a new Epoch (), 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 () pads small Chunks, and each RPF carries a 72-octet header and an authentication tag (). Manifests () 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 ().

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. 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. Remote Usage under Churn and Retention (50 TB, k=10, m=2)

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

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 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.

Rateless Extension Implementations MAY use rateless erasure codes such as RaptorQ 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 .

Remote Parity Fragment Format An RPF is a binary object with the layout in . 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 ().

RPF Layout RPF Header Fields

Field	Size (octets)	Description
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 Index	2	Index of this RPF among the m parity fragments, starting at zero
K	2	Number of Stripe Units in the stripe
M	2	Number of RPFs in the stripe
Key Generation	2	Identifier of the master key generation from which this RPF's key is derived ()
Fragment Length	4	Length of the ciphertext in octets
Nonce	12	AEAD nonce

Implementations SHOULD use a fixed Fragment Length across a Vault so that fragment sizes do not reveal Chunk sizes (). The IANA media type for an RPF container is requested in .

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 ();
the Vault object name of each RPF;
the chunking parameters of , as permitted by the key policy; and
the digest of the preceding Epoch's Manifest, forming a hash chain.

Digests MUST use SHA-256 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.

Transport Requirements A conforming transport MUST provide the following.

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 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 is RECOMMENDED.
Resumable retrieval. The transport MUST support byte-range retrieval of fragments and resumption of an interrupted transfer without restarting completed fragments.
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 . A HyPR Core MUST NOT depend on any provider feature other than object creation, ranged read, listing, and, where available, object-level immutability.

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 () MUST each be derived from the master key using HKDF with a distinct context label per purpose, so that no two purposes share a key. The Rebuild Receipt signing key () 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 () 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 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.

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.

Detecting Degraded Stripes The reconstruction protocol () 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.

Read errors. A read of a Stripe Unit fails with an I/O error, and the unit is treated as missing.
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.
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.
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 (). 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 ().

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.

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.
It opens a resumable, integrity-checked retrieval session with the Vault and fetches only those RPFs.
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.
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 . 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.

Restoring Reconstructed Data Reconstruction () yields verified Stripe Units. This section defines how they are returned to the Local Array.

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 () identifies the file, offset, and length of each Chunk.
Assembly. Replacement files are assembled in the staging location from reconstructed Chunks and surviving local Chunks, and are verified Chunk by Chunk.
Placement. Replacing or modifying a file in the protected tree is a restoration over existing local data and requires explicit operator authorization (). 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 supports one. HyPR does not repair file system structures. If the file system itself is damaged, the operator restores to a new volume.
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.
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.

Advisory Orchestration An Orchestration Agent MAY provide advice on: disk failure prediction from time-series device telemetry ; 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.

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 , 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.

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 and 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 () and fixed fragment sizes mitigate, but do not eliminate, this channel.
Model integrity.: The advisory-only constraints of bound the effect of a compromised, erroneous, or hallucinating model, because it can neither alter data nor perform irreversible actions.
Correlated local failure.: HyPR reduces but cannot eliminate exposure to correlated failure (). 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.

IANA Considerations This document requests registration of the following media type in the standards tree, in accordance with .

Type name:: application
Subtype name:: hypr-rpf
Required parameters:: N/A
Optional parameters:: N/A
Encoding considerations:: binary
Security considerations:: See of this document.
Interoperability considerations:: See .
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 (), with initial values 1, 2, and 3 as defined above and a registration policy of Specification Required.