# Template IETF Project Pack
This directory is a reusable starting point for a new `projects/<name>/` pack for an IETF-formatted RFC effort.
Clone it, rename the directory, and replace every bracketed placeholder before relying on it for drafting.
## What to customize first
1. Rename `projects/template-ietf/` to your real project-pack directory name.
2. Replace all bracketed placeholders such as `[replace: project title]`, `[replace: authoritative source]`, and `[replace: document name]`.
3. Update `suite-brief.md` with the real charter, document list, cross-document boundaries, and non-goals.
4. Update `corpus-brief.md` with the real authoritative corpus, informative material, and evidence-routing rules.
5. Update `references.md` with the actual normative and informative reference pools, terminology ownership, and dependency map.
6. Update `draft-metadata.md` with the true stream, intended status, titles, abstract anchors, and any front-matter constraints.
7. Copy or rename `briefs/document.md` into one brief per real document, then fill in each brief's exact scope, required sections, and review traps.
8. If you stage copied excerpts, sample payloads, or other bulky working material, keep the canonical conclusions in the pack docs and use `references/` only for support material.
## Repo-level IETF tooling guidance
This pack is intentionally about project facts, not render mechanics.
For kramdown-rfc and xml2rfc build/validation behavior, read the repo-level guidance in `../../toolchains/kramdown-rfc-mechanics.md`. That file owns the reusable IETF rendering mechanics such as:
- the kramdown-rfc -> RFCXML -> xml2rfc render path,
- required structural separators in kramdown-rfc source,
- BCP 14 boilerplate mechanics,
- refcache and reference-resolution cautions,
- rendered-text-first example validation.
Do not duplicate those mechanics in this project pack unless the new project truly has additional project-specific constraints.
## Pack contents
- `suite-brief.md` — suite or single-document charter, deliverable boundaries, scope rules, and editorial bias.
- `corpus-brief.md` — authoritative corpus, informative corpus, evidence surfaces, and section-to-source routing.
- `references.md` — curated normative and informative reference pools, terminology ownership, and dependency rules.
- `draft-metadata.md` — shared IETF-oriented front-matter defaults and placeholders that a real project owner must fill in.
- `briefs/document.md` — template for a per-document drafting brief; duplicate or rename it for each real deliverable.
- `references/README.md` — explains support-only staged material and why copied or bulky files should usually stay ignored.
- `examples/README.md` — explains when to add example seeds or anomaly probes.
- `runs/README.md` — checked-in placeholder for the pack-local run root; concrete run artifacts belong under `runs/<run-id>/`.
## Suggested load order for a new project
1. Read this `README.md`.
2. Fill in `suite-brief.md`, `corpus-brief.md`, `references.md`, and `draft-metadata.md`.
3. Create the real document briefs under `briefs/`.
4. Add any example seeds or staged support material only after the canonical pack docs say what governs the project.
5. Keep any repo-local run output under `runs/<run-id>/`, with `runs/README.md` left checked in as the reusable placeholder.
6. Use the repo-level toolchain note in `../../toolchains/kramdown-rfc-mechanics.md` when rendering or validating drafts.
## Intended boundary
This template demonstrates the canonical project-pack shape for IETF work. It should help a new author state:
- what the project is trying to standardize,
- which sources are authoritative,
- which references are normative versus informative,
- which document owns each major term or rule,
- where build mechanics live outside the pack.
If a copied note, export, or local scratch file disagrees with the canonical pack docs, the canonical pack docs win. Keep those canonical pack docs at the top of the pack; concrete run output belongs only under `runs/<run-id>/`.