Template IETF Suite Brief

Use this file to define the suite charter for a real IETF project pack. Replace every bracketed placeholder with project-specific facts.

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]
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:

• [replace: parse or interpret the core artifact/protocol/model]
• [replace: produce interoperable output or requests]
• [replace: validate error cases, limits, or invariants]
• [replace: understand versioning or capability negotiation rules]
• [replace: reconstruct or reproduce the behavior promised by the suite]

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 wire/image format]
• Cross-reference rule: [replace: when to cite another document instead of re-explaining it]
• Vocabulary ownership rule: [replace: which document introduces each important family of terms]

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]
• [replace: implementation-internal behavior not meant for the RFC]
• [replace: deployment-specific tooling, UI, product policy, or operator workflow]
• [replace: adjacent protocols or formats that may be mentioned but are not specified here]

Deliverable boundaries

• Public draft source: [replace: usually kramdown-rfc Markdown]
• Public rendered deliverable(s): [replace: usually IETF .txt, optionally HTML/PDF if the project treats them as published outputs]
• Intermediate artifacts only: [replace: usually .xml and any validation scratch output]
• Publication target: [replace: Internet-Draft only | intended RFC stream/category goal]

State any project-specific rule about what is published versus what is only used for local validation.

Editorial bias

Choose the writing stance the whole suite should follow.

• [replace: self-contained explanation beats terse cross-reference when interoperability is at risk]
• [replace: algorithmic/procedural text is preferred over narrative hand-waving]
• [replace: examples must come from observed output, not synthetic paraphrase]
• [replace: historical behavior must be preserved or explicitly excluded]

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]
• [replace: common confusion between authoritative and informative 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.