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. references.md stays the authoritative versioned reference surface; sibling references/ material is support-only and covered by the default ignore rule, which also matches references/README.md, so a newly created pack may need that placeholder explicitly added/promoted.

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, the already-tracked placeholder contract, and why a newly scaffolded pack's placeholder may need explicit Fossil add/promote because the default ignore rule matches it too.
• 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 support-only staged material only after the canonical pack docs say what governs the project; expect the default ignore rule to cover references/README.md and other files under references/, so explicitly add/promote the new placeholder or any staged file you truly want versioned.
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>/.