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.