Use this when SOSP reviews land and the response window opens. SOSP's response phase has an unusually narrow charter, stated in the CFP (verified 2026-07-08 for the 2026 cycle): responses exist to correct factual errors in the reviews and to answer questions reviewers explicitly posed. They must not add new experiments or data, describe work done since submission, or promise follow-up work. Submitting a response is optional, and while no hard cap is stated, authors are strongly encouraged to stay under 500 words.
The response is read by a program committee that will discuss the paper live at a PC meeting. Its job is to remove false obstacles before that discussion, not to renegotiate the paper.
| Move | Allowed at SOSP? | Why |
|---|---|---|
| "Review B states we hold the lock across I/O; §4.2 shows it is released before the write" | Yes | Factual correction, cites the submitted text |
| Answering "how does this behave when the log fills?" with what the submission already supports | Yes | Direct reviewer question |
| "We have since run the benchmark on 128 nodes and..." | No | New data after the deadline |
| "We will add a comparison against X in the final version" | No | Promised work |
| Re-arguing novelty against a reviewer's taste judgment | Technically allowed, usually wasted words | Not a factual error |
| Pointing to the supplementary document for detail the reviewer missed | Yes, sparingly | It was part of the submission |
Read all reviews once without drafting anything, then classify every negative point:
If categories 1-3 are empty, seriously consider not responding: an optional response that only pushes back on judgments can read worse than silence.
Response skeleton (target < 500 words total)
We thank the reviewers. We correct three factual points and answer two questions.
[Factual] Rev A: "the design requires a second network round trip."
It does not: the token is piggybacked on the existing ack (§3.3, Fig. 4).
[Factual] Rev C: "no failure experiments."
§5.4 and Table 6 report crash-restart and partition runs on the same workloads.
[Question] Rev B asked how recovery time scales with log size.
Recovery replays only the tail past the last checkpoint; §4.5 gives the bound
and Fig. 9 measures it at three log sizes.
[Clarification] Rev A read the consistency guarantee as per-object; it is
per-session (§2, invariant I2). The distinction affects the Rev A example: ...
Every accepted SOSP paper is discussed in front of the whole committee, so your response's audience is wider than the three or four people who reviewed it. Write so a non-reviewer PC member encountering the paper for the first time at the meeting sees authors who are precise, unrattled, and honest about limits. Concede real weaknesses in one clean sentence ("The evaluation does not include workload X; the submitted results cover Y and Z") rather than burying them — a concession you volunteer is a footnote at the meeting, one you dodge becomes the meeting's topic.
[Respond at all?] yes / no (categories 1-3 empty)
[Point map] <review point -> factual error / missed content / question / judgment>
[Word budget] <allocation across points, total target>
[Concession] <the one weakness to own explicitly>
[Compliance check] no new data / no promises / submission-only citations