name: reviewing-ietf-drafts
description: Reviews and critiques IETF Internet-Drafts and RFC submissions for style compliance, technical clarity, prior art gaps, and publication readiness. Use when analyzing existing drafts or providing editorial feedback.
requires:
- writing-ietf-w3c-specs
IETF Draft Reviewer
Systematic review of Internet-Drafts for RFC publication readiness.
When to Use
Use this skill when:
- Reviewing an existing Internet-Draft before submission
- Providing editorial feedback on a colleague's draft
- Checking your own draft against IETF requirements
- Evaluating a draft for technical clarity and completeness
Review Methodology
Phase 1: Structural Scan
Quick pass to verify all required elements are present.
| Element |
Required? |
Check |
| Abstract |
Yes |
Self-contained, no citations |
| Requirements Language (RFC 2119) |
If keywords used |
Boilerplate in Section 2 |
| Terminology |
If domain-specific terms |
Definitions before first use |
| Security Considerations |
Always |
Substantive content |
| IANA Considerations |
Always |
Even if "no actions" |
| Internationalization |
If applicable |
Character sets, localization |
| References |
Yes |
Normative/Informative split |
Phase 2: Style Compliance (RFC 7322)
Detailed review against RFC Style Guide.
Requirement Keywords
| Issue |
Example |
Severity |
| Lowercase normative |
"should validate" |
HIGH - change to SHOULD |
| MUST in informational text |
"Users MUST read the docs" |
MEDIUM - use lowercase |
| Ambiguous modal |
"may or may not" |
HIGH - clarify intent |
| Missing RFC 2119 reference |
Keywords used, no boilerplate |
HIGH - add Section 2 |
Citation Format
| Wrong |
Correct |
[1] |
[RFC2119] |
(see page 5) |
(see Section 3.1) |
RFC 2119 inline |
[RFC2119] |
| Mixed normative/informative |
Separate reference sections |
Text Format
| Issue |
Recommendation |
| Lines > 72 chars in diagrams |
Reformat to fit |
| Tabs in source |
Convert to spaces |
| Non-ASCII characters |
Use ASCII equivalents or declare UTF-8 |
| Orphan headers |
Keep header with following paragraph |
Phase 3: Technical Clarity
Evaluate whether the specification is implementable.
Precision Checklist
Ambiguity Flags
| Pattern |
Problem |
Fix |
| "appropriate" |
Undefined |
Specify criteria |
| "reasonable" |
Subjective |
Give bounds |
| "typically" |
Non-normative |
Use SHOULD or document exceptions |
| "etc." |
Incomplete |
Enumerate or use "and others" |
| "as needed" |
Vague |
Define triggers |
Phase 4: Prior Art & Conflicts
Related Work Check
- RFC Search: Does the draft cite all relevant existing RFCs?
- I-D Search: Any active drafts covering similar ground?
- WG Conflict: Is an IETF Working Group already addressing this?
- Updates/Obsoletes: If modifying existing RFC, is metadata correct?
Conflict Indicators
| Signal |
Risk |
Action |
| Active WG on same topic |
High |
May get DNP (Do Not Publish) |
| Recent RFC in same area |
Medium |
Ensure proper citations |
| Competing I-D |
Medium |
Differentiate or consolidate |
| Patent mentions |
Variable |
Verify IPR disclosure |
Phase 5: Publication Readiness
Stream Appropriateness
| Stream |
Valid Status |
Consensus Required |
| IETF |
Standards Track, BCP, Info, Exp |
Yes |
| Independent |
Informational, Experimental, Historic |
No |
| IRTF |
Informational, Experimental |
IRSG |
| IAB |
Informational |
IAB |
Blocking Issues
| Issue |
Impact |
Resolution |
| Normative ref to unpublished I-D |
MISSREF state |
Make informative or wait |
| Missing IANA registry policy |
Blocks publication |
Add per RFC 8126 |
| No Security Considerations |
Rejected |
Add substantive section |
| IPR not disclosed |
Legal risk |
File IPR disclosure |
Review Output Template
When reviewing a draft, produce a report with this structure:
# Review: draft-name-version
## Summary
[One paragraph overall assessment]
## Structural Issues
- [ ] Issue 1
- [ ] Issue 2
## Style Violations
| Location | Issue | Recommendation |
|----------|-------|----------------|
| Section X | ... | ... |
## Technical Clarity
[Ambiguities, undefined terms, missing edge cases]
## Prior Art Gaps
[Missing citations, potential conflicts]
## Publication Blockers
[Issues that MUST be resolved before submission]
## Recommendations
1. Priority fix 1
2. Priority fix 2
...
Common Issues by Section
Abstract
| Issue |
Example |
Fix |
| Contains citations |
"as defined in [RFC9110]" |
Remove, describe inline |
| Undefined acronyms |
"TLS" |
Expand: "Transport Layer Security (TLS)" |
| Too long |
> 200 words |
Condense to essential description |
| Not self-contained |
"See Section 3" |
Remove cross-references |
Security Considerations
| Issue |
Example |
Fix |
| Empty/trivial |
"No security considerations" |
Never acceptable; find real issues |
| Generic |
Copy-paste boilerplate |
Tailor to specific protocol |
| Missing threat model |
Lists attacks without context |
Add threat model section |
| No mitigations |
Identifies risks, no solutions |
Add recommended countermeasures |
Required Coverage:
- Threat model assumptions
- Authentication/authorization
- Confidentiality/integrity
- Replay protection
- Denial of service
- Privacy implications
IANA Considerations
| Issue |
Example |
Fix |
| Missing when needed |
Defines new registry values |
Add IANA section |
| Wrong registration policy |
Uses "First Come First Served" for security-sensitive |
Use "Specification Required" |
| Missing template |
New registry without fields |
Add registration template |
| Placeholder not resolved |
"TBD" in final draft |
Get actual values |
References
| Issue |
Example |
Fix |
| Normative ref to I-D |
Blocks on unpublished work |
Reconsider dependency |
| Missing DOI |
RFC without DOI |
Add DOI |
| Outdated RFC |
Cites obsoleted RFC |
Update to current |
| URL-only reference |
External spec by URL only |
Add full bibliographic entry |
Quick Reference: Severity Levels
| Severity |
Description |
Action |
| BLOCKER |
Prevents publication |
Must fix before submission |
| HIGH |
Violates IETF requirements |
Should fix, may cause IESG review issues |
| MEDIUM |
Style guide violation |
Recommended fix |
| LOW |
Editorial suggestion |
Optional improvement |
Reviewer Workflow
1. Read abstract and introduction
└─> Understand scope and claims
2. Structural scan (Phase 1)
└─> Verify all required sections present
3. Read Security and IANA sections
└─> Most common failure points
4. Detailed style review (Phase 2)
└─> Check RFC 7322 compliance
5. Technical deep-dive (Phase 3)
└─> Implementability assessment
6. Prior art search (Phase 4)
└─> Conflict and citation check
7. Publication assessment (Phase 5)
└─> Stream appropriateness, blockers
8. Generate report
└─> Use template, prioritize findings
References
By