NPR Enhancement Proposals (NEP) » NEP-0001: NPR Enhancement Proposal Process

Abstract

This document defines the NPR Enhancement Proposal (NEP) process.

A NEP is the primary mechanism for proposing substantial changes to the NPR protocol, NPR implementations, NPR operational practice, and NPR governance. A NEP provides a durable design record, a forum for structured technical review, and a stable reference for implementers and operators.

This document defines:

• the NEP lifecycle and statuses,
• the classes of NEP,
• the required sections of a NEP,
• authorship and review expectations,
• conventions for normative language, compatibility statements, and security analysis.

Motivation

NPR is a protocol used in constrained amateur-radio environments, often on low-cost and slow hardware, and often under adverse RF conditions. Changes to NPR therefore need to be documented with unusual care.

A proposal that is only discussed in chat, source comments, or commit messages is hard to review, easy to misunderstand, and easy to lose. NEPs exist to make NPR evolution reviewable, archivable, and implementable.

Goals

The NEP process has the following goals:

1. To preserve technical rationale, not just final decisions.
2. To make backward-compatibility and operational trade-offs explicit.
3. To encourage designs appropriate for amateur-radio use, including simplicity, low on-air overhead, modest memory use, and tolerance of weak or missing infrastructure.
4. To separate speculative ideas from accepted protocol changes.
5. To give implementers a stable citation target.

Non-Goals

This document does not define:

• the complete governance model of any specific NPR project,
• a mandatory source repository structure,
• a mandatory release cadence,
• a requirement that every code change have its own NEP.

Small bug fixes, editorial corrections, test improvements, and local implementation details MAY proceed without a NEP unless they affect protocol behavior, interoperability, wire format, or operator-visible semantics.

Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in NEPs are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. ([rfc-editor.org][2])

For the purposes of NEPs:

• NPR means the protocol family and associated interoperable behavior.
• Implementation means a concrete NPR firmware, modem, host stack, or tooling implementation.
• Operator means a human configuring, deploying, or monitoring NPR equipment.
• Wire format means any over-the-air or on-link serialized representation.
• Backward compatible means that an older compliant implementation continues to operate without misparsing or protocol failure, though it MAY ignore unknown extensions.

NEP Types

NEPs are classified into one of the following types:

Standards Track

A Standards Track NEP proposes one or more of:

• a protocol extension,
• a wire-format change,
• a new message type,
• new state-machine behavior,
• a new interoperability requirement,
• a normative operational rule needed for interoperability.

A Standards Track NEP is the usual choice for protocol work.

Informational

An Informational NEP describes background, design guidance, operating practice, threat models, examples, deployment notes, or rationale. It does not by itself change the protocol.

Process

A Process NEP changes the way the NPR project governs itself, writes specifications, reviews proposals, assigns numbers, or manages compatibility policy.

NEP Statuses

A NEP has exactly one status.

Draft

The proposal is being actively written and reviewed. It is incomplete and subject to change.

Accepted

The proposal has been accepted in principle and is part of the intended NPR direction. An Accepted NEP MAY still await implementation.

Final

The proposal has been implemented and is considered stable enough to serve as normative reference material.

Provisional

The proposal is implemented and intended for real use, but experience is still being gathered and incompatible adjustments remain possible.

Deferred

The proposal is not rejected, but work is postponed.

Rejected

The proposal will not be adopted in its current form.

Withdrawn

The author or maintainer has withdrawn the proposal.

Superseded

The proposal has been replaced by one or more later NEPs.

NEP Header Preamble

Each NEP MUST begin with a header containing at least the following fields:

• NEP
• Title
• Author
• Status
• Type
• Created

The following fields are OPTIONAL but RECOMMENDED where applicable:

• Requires
• Replaces
• Replaced-By
• Target-Version
• Discussion
• Resolution

Header fields SHOULD be brief, machine-readable where practical, and stable once published, except where updated by process.

Required Sections of a Standards Track NEP

A Standards Track NEP MUST contain, at minimum, the following sections:

1. Abstract A concise summary of the proposal.
2. Motivation Why the change is needed, including operational and interoperability problems being solved.
3. Specification The normative behavior. This section MUST be sufficient for independent implementation.
4. Rationale Why the chosen design was selected over alternatives.
5. Backward Compatibility Exact behavior with older masters, slaves, tools, frames, and parsers.
6. Security Considerations Threat model, mitigations, non-goals, and residual risks.
7. IANA-like Considerations Any type numbers, registries, capability bits, or allocation rules introduced by the proposal.
8. Reference Implementation Optional in early drafts, but RECOMMENDED before Final status.
9. References Normative and informative references.

The following sections are OPTIONAL but RECOMMENDED when relevant:

• State Machines
• Wire Format
• Timing Requirements
• Operational Considerations
• Migration Strategy
• Test Vectors
• Example Frames

Required Qualities of a NEP

A NEP SHOULD be:

• technically precise,
• specific about on-air cost,
• explicit about memory and CPU complexity when relevant,
• explicit about failure modes,
• explicit about timeouts and replay windows,
• explicit about whether behavior is mandatory or discretionary.

A Standards Track NEP MUST NOT leave wire-format behavior to guesswork if interoperability depends on it.

A Standards Track NEP MUST state whether unknown fields are ignored, rejected, or cause downgrade behavior.

Compatibility Policy

Every Standards Track NEP MUST contain a section named Backward Compatibility.

That section MUST answer, for every relevant pairing:

• old master / old slave
• new master / old slave
• old master / new slave
• new master / new slave

Where relevant, it MUST also answer:

• behavior when authentication, authorization, or policy is disabled,
• behavior when an implementation supports the extension but the peer does not,
• behavior when a frame carries unknown TLV elements or extra trailing bytes.

Backward compatibility claims SHOULD be stated in concrete operational terms, not only abstractly.

Security Analysis Expectations

Every Standards Track NEP MUST include a threat model appropriate to amateur-radio reality.

A good Security Considerations section SHOULD address, as applicable:

• spoofing,
• replay,
• downgrade,
• resource exhaustion,
• frame amplification,
• malformed frame handling,
• persistent-state requirements,
• weak or absent real-time clocks,
• weak or absent secure storage,
• operator misconfiguration,
• denial-of-service through RF contention,
• risks accepted deliberately for simplicity or spectrum efficiency.

When a proposal does not provide confidentiality, integrity for all traffic, or perfect anti-replay guarantees, it SHOULD say so plainly.

Number Assignment

NEP numbers are assigned sequentially. Once assigned, a NEP number MUST NOT be reused.

A withdrawn, rejected, or superseded NEP retains its number for historical reference.

Change Control

A Draft NEP MAY change substantially.

An Accepted or Provisional NEP SHOULD be changed carefully, with visible revision history.

A Final NEP MUST NOT be rewritten in a way that changes technical meaning. Errata, clarifications, and references MAY be added. Substantive new work requires a new NEP that updates, replaces, or obsoletes the earlier one.

Review and Acceptance

A NEP author is responsible for the technical content of the proposal.

Reviewers are responsible for scrutiny, not authorship. Acceptance of a NEP does not transfer responsibility for correctness away from the author.

A Standards Track NEP SHOULD receive review from:

• at least one protocol implementer,
• at least one operator familiar with NPR deployment constraints,
• at least one reviewer specifically considering security and misuse cases.

Acceptance criteria SHOULD include:

• technical soundness,
• implementability on constrained hardware,
• acceptable on-air cost,
• clearly specified compatibility behavior,
• clear operator-facing consequences.

Style

NEPs SHOULD be written in clear technical English.

A NEP SHOULD prefer precise prose over marketing language.

A NEP SHOULD distinguish clearly between:

• normative requirements,
• rationale,
• examples,
• open questions.

A NEP SHOULD avoid unexplained jargon when simpler language will do.

The overall style of NEPs is inspired by the organizational role of PEP 1 and by the normative style conventions commonly used in RFCs. ([Python Enhancement Proposals (PEPs)][1])

References

Normative References

• RFC 2119, Key words for use in RFCs to Indicate Requirement Levels. ([rfc-editor.org][2])
• RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. ([rfc-editor.org][3])

Informative References

• PEP 1, PEP Purpose and Guidelines. ([Python Enhancement Proposals (PEPs)][1])