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