# Template IETF Suite Brief
Use this file to capture the project-specific charter for a real IETF pack. It inherits the reusable IETF defaults from this template; record only the project facts and any deliberate overrides.
## Defaults already assumed
- Draft source is kramdown-rfc Markdown in `.md` files.
- Public rendered output is `.txt`; `.xml` is an intermediate artifact unless the project says otherwise.
- Repo-level render mechanics stay in `../../toolchains/kramdown-rfc-mechanics.md`.
- Per-document briefs inherit the standard RFC section skeleton and the normative/informative reference split.
## 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, or delete if single-document]`
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:
- parse or interpret `[replace: the core artifact / protocol / data model]`
- produce interoperable `[replace: output, request, document, or behavior]`
- validate `[replace: error cases, limits, or invariants]`
- understand `[replace: versioning, negotiation, compatibility, or dependency rule]`
- reconstruct or reproduce `[replace: the suite-level behavior promised by the documents]`
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 behavior]`
- **Cross-reference rule:** Cite the owning document instead of re-explaining its full normative content, unless repetition is required for interoperability clarity.
- **Vocabulary ownership rule:** Each important term family should have one named owner in the suite or an external RFC.
## 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]`
- implementation-internal behavior that is not part of the public interoperability contract
- deployment-specific tooling, UI, product policy, or local operator workflow
- `[replace: adjacent protocols or formats that may be mentioned but are not specified here]`
## Deliverable boundaries
Unless the project overrides these defaults:
- **Public draft source:** kramdown-rfc Markdown `.md`
- **Public rendered deliverable:** rendered `.txt`
- **Intermediate artifacts only:** RFCXML `.xml` plus validation scratch output
- **Publication target:** Internet-Draft workflow until the project owner sets the actual stream / intended status in `draft-metadata.md`
Record only the project-specific exceptions here, such as additional published outputs or a non-default publication policy.
## Editorial bias
These defaults are usually reusable across IETF projects; override only if this project needs a different stance.
- self-contained explanation beats terse cross-reference when interoperability is at risk
- algorithmic or procedural text beats narrative hand-waving for normative behavior
- examples should come from observed output or re-validated artifacts, not synthetic paraphrase
- historical behavior should be either preserved explicitly or excluded explicitly
## 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]`
- confusion between authoritative evidence and orientation-only 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.