SIGCOMM Author Response

SIGCOMM has two distinct author-facing replies, and conflating them is a strategic error. The rebuttal is a short argument during the discussion phase; the one-shot revision is a month-long, shepherd-managed contract. Reopen the current CFP to confirm the mechanics before drafting.

First, know which reply you are writing

Writing the rebuttal

• Answer the concern that decides the paper first: evaluation realism, a missing baseline, a correctness question, or a generalization doubt. Style complaints wait.
• Anchor every answer in evidence already in the submission — a table, a figure, an appendix measurement — rather than promising new experiments the reviewers cannot see.
• Stay anonymous: no institution, deployment name, or private link that breaks double-blind.
• Concede cleanly what cannot be fixed in the window, and scope a camera-ready wording change instead of overclaiming a result you cannot produce now.
• One precise, decision-focused reply per reviewer beats an exhaustive point-by-point that buries the objection that actually matters to the discussion.

Executing the one-shot revision

The revised paper can only be accepted or rejected, so the required-changes list is the grading rubric. Build the packet the CFP expects:

1. Point-by-point response mapping each required change to exactly what you did and where.
2. Change-marked manuscript so the shepherd and reviewers see the diff without hunting.
3. List of changes at a high level, so a reader gets the shape before the detail.

Then work the contract, not the margins:

• Address every listed issue explicitly; a revision that improves adjacent things but dodges a listed item is the classic one-shot rejection.
• Engage the shepherd through HotCRP early — clarify an ambiguous requirement before you build the wrong fix, not after.
• Keep results honest to the new evidence; if a required experiment weakens a claim, rescope the claim rather than hiding the outcome.

Reviewer pushback patterns and SIGCOMM-ready fixes

Micro-example (revision)

Reviewer requires a comparison against the deployed state-of-the-art at matched throughput. Packet skeleton: (1) response entry naming the added baseline and the section/table that now holds it; (2) change-marked Section 5 with the new column; (3) change-list line "Added state-of-the-art baseline X at matched throughput (Table 2)." No unlisted claims sneak in.

Output format

[Reply type] rebuttal / one-shot revision / n-a (early reject)
[Priority issue] <the objection that decides the outcome>
[Evidence anchor] <table / figure / appendix / new run>
[Revision packet] response / marked diff / change list — status
[Shepherd touchpoint] <what to confirm before building>
[Forbidden content removed] <identity leaks, unlisted new claims>