Rights Layer Specification

RFC Process

Status: Draft v0.1.0 — This section is normative for how the specification itself is changed.

The Rights Layer Specification changes through a public Request for Comments (RFC) process. This document defines when an RFC is required, the stages an RFC passes through, the RFC template, numbering, and where RFCs live. Who decides is defined in GOVERNANCE.md.

When an RFC is required

An RFC is REQUIRED for any normative change, including:

• changes to Terminology — adding, removing, or redefining a term;
• changes to the Conceptual Model;
• changes to the Data Model;
• changes to the schema (anything under schema/);
• changes to the Core Principles — amending a principle is always an RFC;
• changes to normative governance rules (decision making, roles, the neutrality safeguard, versioning policy);
• introducing or changing the normative parts of extension points and profiles.

An RFC is NOT required for editorial fixes (typos, links, formatting, wording that does not change meaning), informative examples, or repository housekeeping. When in doubt, open an issue and ask; a maintainer will decide whether the change is normative.

Stages

An RFC moves through the following stages. The current stage is recorded in the RFC document’s header.

1. Draft. The author writes the RFC using the template below and submits it as a pull request adding a file to the rfcs/ directory. A maintainer assigns the RFC number.
2. Discussion. The RFC is discussed publicly on its pull request (and, optionally, a linked discussion thread). The author revises the RFC in response. There is no fixed time limit; an RFC may stay in Discussion as long as it is actively evolving. An author may withdraw an RFC at any stage before acceptance.
3. Last Call. When discussion has converged, a maintainer announces Last Call with a stated review period of at least 14 days. Last Call is the final opportunity to object. Substantive changes during Last Call return the RFC to Discussion.
4. Accepted / Rejected. At the end of Last Call the decision is made per GOVERNANCE.md: lazy consensus, falling back to a maintainer vote. An RFC that violates an unamended Core Principle MUST be rejected regardless of support. The outcome and its rationale are recorded in the RFC document.
5. Merged. For an accepted RFC, the specification text is updated to implement it (in the same or a follow-up pull request), the change is recorded in CHANGELOG.md, and the RFC is marked Merged. The RFC file remains in the repository permanently as the record of the decision. Rejected and withdrawn RFCs are also kept, marked with their final status.

RFC template

Every RFC MUST contain at least the following sections:

# RFC-NNNN: Title

- Status: Draft | Discussion | Last Call | Accepted | Rejected | Withdrawn | Merged
- Author(s): (name or handle)
- Created: YYYY-MM-DD
- Discussion: (link to pull request / thread)

## Motivation

What problem does this solve? Why is the current specification
insufficient? Include concrete use cases where possible.

## Proposal

The actual change, precisely. For terminology/model/schema changes, include
the proposed normative text or schema diff.

## Impact on Core Principles

State, for each affected principle, why the proposal complies with it — or,
if it does not, which principle amendment this RFC proposes. A proposal
that is silent on a principle it plainly touches is incomplete.

## Compatibility

Effect on existing conforming expressions and implementations: is this
backward compatible? What semver level does it imply (major/minor/patch)?
Migration guidance if breaking.

## Alternatives

Alternatives considered, including doing nothing, and why they were not
chosen. Where relevant, note existing open standards evaluated per
Principle P8 (minimal invention, maximal reuse).

Additional sections (open questions, prior art, drawbacks) MAY be added.

Numbering

RFCs are numbered sequentially in the form RFC-0001, RFC-0002, … Numbers are assigned by a maintainer when the Draft pull request is opened, are never reused, and are permanent — a rejected or withdrawn RFC keeps its number. These numbers identify Rights Layer RFCs only; they are unrelated to IETF RFC numbers.

Where RFCs live

RFCs live in the rfcs/ directory at the repository root, one file per RFC, named rfcs/RFC-NNNN-short-title.md (e.g. rfcs/RFC-0001-delegation-modeling.md). An index of RFCs and their statuses SHOULD be maintained at rfcs/README.md.

Who decides

Decisions on RFCs are made as defined in GOVERNANCE.md: lazy consensus by default, maintainer vote as fallback, always constrained by the Core Principles.

This site is open source. Improve this page.