Mobicom author response

MobiCom Author Response

MobiCom gives authors two distinct response instruments, and they are not the same job. The rebuttal is a short, bounded reply after round-2 reviews. The one-shot revision is a months-long contract against a required-changes list. Using rebuttal tactics on a revision, or revision ambition in a rebuttal, wastes both.

Triage first, for either instrument

Read all reviews once for facts, then sort every point:

Class	Definition	Response posture
Factual error	reviewer misread the paper	correct crisply, cite the section/figure
Answerable question	a real gap you can address in the space/time	answer with the specific evidence
Valid weakness	a fair criticism you cannot fully fix now	concede honestly; state what you will/can do
Scope disagreement	reviewer wanted a different paper	acknowledge; defend the chosen scope briefly

The same reviewers usually carry the paper forward (mobicom-review-process), so credibility compounds — a fair concession is worth more than winning every argument.

Writing the rebuttal

The rebuttal is short and lands on a fixed clock; its exact length/format is 待核实 for the current cycle, so read the instructions and budget to them.

Rebuttal structure (fit to the length limit):
  1. Open with the 1-2 issues that most affect the decision — not point R1.1.
  2. Correct factual misreadings with a section/figure pointer.
  3. Answer the highest-severity questions with concrete evidence (a number, a
     condition), not a promise to "consider it."
  4. Concede real weaknesses plainly; say what is fixable and what is out of scope.
  5. Do not introduce a new contribution or new claims the reviewers cannot check.

Rules that keep a rebuttal from backfiring:

• No new unverifiable claims. A rebuttal is not a place to add an experiment the reviewers cannot see; it invites distrust.
• Answer, do not deflect. "We will address this in the final version" is a non-answer to a substantive question.
• Promises become obligations. Anything you commit to is the revision/camera-ready checklist — do not promise what you cannot measure.

Executing the one-shot revision

A one-shot revision is a contract: reviewers list required changes; you return the paper against that list, re-reviewed by the same reviewers where possible.

Revision packet:
  - change-highlighted PDF (edits visibly marked)
  - change summary mapping EACH required item -> the visible change that addresses it
  - the revised paper within the same 12-page double-column cap

• Map every required item to a visible change. A revision that silently skips an item, or argues it away without addressing it, is the fastest path to a terminal reject.
• Re-run in the requested condition. If a reviewer asked for a mobility or interference experiment, adding a different experiment does not discharge the item.
• Cost it before committing. Size the demanded experiments in testbed-weeks against the revision deadline (mobicom-workflow); a revision that arrives incomplete is worse than one that was planned realistically.

Consistency across the arc

Your rebuttal, revision, and camera-ready are read as one record by continuing reviewers. Contradicting an earlier response — walking back a conceded weakness, or dropping a promised experiment — is a memorable red flag. Keep a running log of every commitment made.

Output format

[Instrument] rebuttal / one-shot revision
[Triage] points classified: factual / question / weakness / scope
[Rebuttal] lead issues chosen; concessions listed; new-claim check passed
[Revision] required-items -> change map; conditions re-run as asked
[Commitments] running list that becomes the next-stage checklist