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:
[replace: document title or deliverable A][replace: document title or deliverable B][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.