| name | nsdi-author-response |
| description | Use when answering NSDI reviewers through the channel the venue actually provides — executing a one-shot revision against the required-issues list, writing the change memo and highlighted diff for the same reviewers, and pre-empting objections inside the submission when no response phase exists. |
NSDI Author Response
At NSDI the author's voice reaches reviewers at two moments only: inside the original
submission, and — if granted — inside a one-shot revision packet read by the same
people who wrote the demands. There is no rendered rebuttal phase in the '27 CFP
(absence 待核实; verify each cycle). This skill covers both moments; the second is
the venue's signature mechanism and the reason this skill is not a rebuttal-writing
guide.
Moment one: the response you embed in advance
Without a mid-review channel, anticipated objections must be answered in the PDF:
- Run the objection drill: each coauthor writes the three most likely reviewer
complaints; any complaint appearing twice gets a paragraph in the paper —
typically a "why not X?" design-alternatives note or a limits paragraph
(
nsdi-writing-style).
- Pre-empt the baseline attack by documenting baseline tuning in-body
(
nsdi-experiments).
- Pre-empt the scope attack with an explicit sentence locating the contribution in
the networking stack or distributed design (
nsdi-topic-selection).
Moment two: the one-shot revision, treated as a contract
The decision letter's required-issues list is an offer with exact terms: fix these,
same reviewers check, one attempt. Respond like a contractor, not a debater.
Triage the issues within days of notification:
| Issue type | Typical cost | Response posture |
|---|
| New experiment / baseline | machine-weeks + testbed access | reserve infrastructure immediately (nsdi-workflow) |
| Analysis or clarity | days | do fully; these are free credibility |
| Claim recalibration | hours, plus ego | almost always concede — narrow the claim to the evidence |
| Genuinely infeasible demand | — | contact the program co-chairs early; silence then surprise is the worst path |
Execution rules:
- Address every listed issue, visibly. Coverage is binary at NSDI: revisions
that fail to address the required issues are rejected with no further revision
option. Partial credit does not exist.
- Do not renovate beyond the list. The same reviewers approved everything they
did not flag; gratuitous rewrites reopen settled sections and can introduce new
objections that the one-shot format gives you no chance to answer.
- If an experiment's result contradicts the reviewer's expectation, report it
straight. The issue said "evaluate under churn," not "show churn is fine." An
honest unfavorable result plus a scoped claim is a fulfilled requirement; a
massaged favorable one is a rejection when the reviewer probes.
The packet: memo + highlighted diff
Both components are mandatory auxiliary material (nsdi-supplementary). Their shared
purpose: let a reviewer verify their own issue in under a minute.
Change memo skeleton (one block per required issue, in the letter's order):
R-1 Compare against <deployed system>.
DONE — §6.2 now includes tuned <system> (config: App. C).
Result: our gains drop from 3.4x to 2.6x at p99.9; text and
abstract recalibrated. [diff pages 8-9, 1]
R-2 Clarify lease-expiry semantics.
DONE — new §4.3 (state machine, Fig. 5); two corner cases we
had not specified are now explicit. [diff pages 5-6]
Also changed (minimal): fixed two typos flagged in reviews; updated
citation [31] to its published version. No other content changes.
The "Also changed" section builds the trust the format depends on — it certifies the
diff is complete. Generate the highlighted version mechanically (latexdiff or
equivalent) from the true submitted baseline, not from a reconstructed one.
Tone: the readers already invested in this paper — a one-shot revision means
they voted to see it again. Write as a colleague closing out a punch list:
no re-argument of the original decision, no flattery, no hedging about what was
and wasn't done.
Timeline for a typical revision window
A spring '27 one-shot revision (notified July 23, 2026) targeting the fall gate
(September 17, 2026) has roughly eight weeks:
- Week 1: issue ledger built; infeasibility flags raised with co-chairs if any;
testbed time reserved.
- Weeks 2-5: demanded experiments run with full provenance
(
nsdi-reproducibility); text changes drafted in parallel.
- Week 6: memo and diff assembled from the running drafts; internal reviewer
plays the original R2 against the packet.
- Week 7: freeze; verify the resubmission enters the correct HotCRP site with
the packet attached (
nsdi-submission).
- Week 8: buffer — the revision that arrives calm beats the one that arrives
complete-but-chaotic at 11:58 pm.
A fall-issued revision aiming at the next edition's spring gate has more calendar
but the same structure; do not let the longer runway defer the testbed reservation.
When the letter says plain reject
There is no response channel and no appeal-by-email; the ban clock runs
(nsdi-review-process). The productive move is extraction: convert each review
point into either a fix, a re-route signal, or a documented disagreement to handle
in the next version's pre-emption layer. The reviews were written by this
community; the next PC will resemble them.
Output format
[Channel] pre-emption (drafting) / one-shot revision (letter in hand)
[Issue ledger] R-# -> action -> cost -> owner -> status
[Feasibility] any issue needing co-chair contact? deadline realistic?
[Packet status] memo issue-complete? diff from true baseline? extras declared?
[Risk] unfavorable-result handling; renovation creep check
[Ship date] resubmission gate targeted, freeze date set
