# Template IETF Suite Brief

Use this file to define the suite charter for a real IETF project pack. Replace every bracketed placeholder with project-specific facts.

## Objective

Produce `[replace: one RFC | a multi-document Internet-Draft suite | companion documents]` covering:

1. `[replace: document title or deliverable A]`
2. `[replace: document title or deliverable B]`
3. `[replace: additional deliverable if needed]`

Short charter:

> [replace: one paragraph stating what the project standardizes, who needs it, and what a clean-room implementer or reviewer should be able to do after reading the deliverable set]

## Required clean-room capabilities

A competent reader who has not seen the source corpus should be able to:

- `[replace: parse or interpret the core artifact/protocol/model]`
- `[replace: produce interoperable output or requests]`
- `[replace: validate error cases, limits, or invariants]`
- `[replace: understand versioning or capability negotiation rules]`
- `[replace: reconstruct or reproduce the behavior promised by the suite]`

If the pack covers multiple documents, add a subsection per document describing the exact clean-room capabilities that document must enable.

## Cross-document structure

Use this section to assign ownership so documents do not duplicate or contradict one another.

- **Foundational document(s):** `[replace: which document owns the core model, terminology, or format]`
- **Dependent document(s):** `[replace: which document depends on another document for definitions or wire/image format]`
- **Cross-reference rule:** `[replace: when to cite another document instead of re-explaining it]`
- **Vocabulary ownership rule:** `[replace: which document introduces each important family of terms]`

## Scope boundaries

### In scope

- `[replace: target protocol, format, API surface, data model, or behavior family]`
- `[replace: versions, compatibility window, deployment class, or interoperability target]`
- `[replace: what implementers or operators must be able to do]`

### Out of scope

- `[replace: legacy versions or paths to exclude]`
- `[replace: implementation-internal behavior not meant for the RFC]`
- `[replace: deployment-specific tooling, UI, product policy, or operator workflow]`
- `[replace: adjacent protocols or formats that may be mentioned but are not specified here]`

## Deliverable boundaries

- **Public draft source:** `[replace: usually kramdown-rfc Markdown]`
- **Public rendered deliverable(s):** `[replace: usually IETF .txt, optionally HTML/PDF if the project treats them as published outputs]`
- **Intermediate artifacts only:** `[replace: usually .xml and any validation scratch output]`
- **Publication target:** `[replace: Internet-Draft only | intended RFC stream/category goal]`

State any project-specific rule about what is published versus what is only used for local validation.

## Editorial bias

Choose the writing stance the whole suite should follow.

- `[replace: self-contained explanation beats terse cross-reference when interoperability is at risk]`
- `[replace: algorithmic/procedural text is preferred over narrative hand-waving]`
- `[replace: examples must come from observed output, not synthetic paraphrase]`
- `[replace: historical behavior must be preserved or explicitly excluded]`

## Review traps to call out early

Record the mistakes a drafter is most likely to make if this file stays vague.

- `[replace: topic that is often duplicated across documents]`
- `[replace: rule that looks editorial but is actually interoperability-critical]`
- `[replace: legacy behavior that must be preserved or explicitly excluded]`
- `[replace: common confusion between authoritative and informative material]`

## What this file should not do

Do not use `suite-brief.md` for:

- tool installation steps,
- kramdown-rfc/xml2rfc render mechanics already covered by `../../toolchains/kramdown-rfc-mechanics.md`,
- local shell recipes or harness-specific runner logic,
- copied source excerpts that belong under `references/` as support material.