# Template IETF Project Pack
This directory is a reusable starting point for a new `projects/<name>/` pack for an IETF-formatted RFC effort.
It already bakes in the common IETF defaults that usually repeat from project to project. Customize the pack with project facts and overrides; do not restate generic RFC structure unless this project genuinely differs.
## Defaults you inherit unless you override them
- Draft source is **kramdown-rfc Markdown** in `.md` files.
- The public rendered deliverable is **plain-text `.txt`**.
- **RFCXML `.xml`** and validator output are intermediate artifacts, not the default public deliverable.
- `references.md` is the pack-level curated reference pool.
- Per-document briefs assume the common RFC section skeleton:
- Introduction
- Conventions and Terminology, including the BCP 14 note when requirement keywords are used
- the document's normative heart, renamed to the real protocol / format / data-model section
- Security Considerations
- IANA Considerations, with an explicit no-action stance unless the project really needs registrations
- normative versus informative references
- Repo-level kramdown-rfc and xml2rfc mechanics live in `../../toolchains/kramdown-rfc-mechanics.md`, not in this pack.
## Inputs the project owner still must supply
These do **not** have safe generic defaults:
- the real document set and which document owns which topic
- the actual normative scope, exclusions, and clean-room capabilities
- the authoritative corpus, evidence-routing rules, and conflict-resolution rule between sources
- the real normative and informative references, terminology ownership, and dependency map
- per-document titles, abstract promises, authors/editors, stream, intended status, and any stream- or WG-specific front matter
- any project-specific provenance wording, publication policy, example policy, or staged reference material
## What to customize first
1. Rename `projects/template-ietf/` to your real project-pack directory name.
2. Update `suite-brief.md` with the actual charter, deliverables, cross-document ownership, and scope boundaries.
3. Update `corpus-brief.md` with the authoritative corpus, informative material, evidence surfaces, and section-to-source routing.
4. Update `references.md` with the real normative and informative reference pools, terminology ownership, and dependency map.
5. Update `draft-metadata.md` with the real titles, authors/editors, stream, intended status, abstract anchors, and any front-matter overrides.
6. Copy or rename `briefs/document.md` into one brief per real document, then specialize the default section skeleton for each document's normative heart, dependencies, examples, and review traps.
7. 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 defaults plus the front-matter fields that remain project-specific.
- `briefs/document.md` — per-document brief template with the default RFC section skeleton already filled in.
- `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`, keeping the inherited IETF defaults unless the project needs overrides.
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,
- which front-matter fields are still human decisions,
- 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>/`.