IEEE Internet of Things Journal Response to Reviewers: A Rebuttal That Survives Re-Review (2026)
Pre-submission and post-decision rebuttal guide for IEEE Internet of Things Journal authors. The same associate editor and the same reviewers read your response next round, so the rebuttal has to do real work.
Readiness scan
Find out if this manuscript is ready to submit.
Run the Free Readiness Scan before you submit. Catch the issues editors reject on first read.
How to use this page well
These pages work best when they behave like tools, not essays. Use the quick structure first, then apply it to the exact journal and manuscript situation.
Question | What to do |
|---|---|
Use this page for | Building a point-by-point response that is easy for reviewers and editors to trust. |
Start with | State the reviewer concern clearly, then pair each response with the exact evidence or revision. |
Common mistake | Sounding defensive or abstract instead of specific about what changed. |
Best next step | Turn the response into a visible checklist or matrix before you finalize the letter. |
Quick answer: An IEEE Internet of Things Journal response to reviewers is a point-by-point rebuttal letter, opened by a short note to the associate editor, that quotes each reviewer comment, states the exact change, and cites the page and line number in the revised manuscript. The decisive detail authors miss: the journal's associate editor guideline says no new reviewers are invited in later rounds, so the same reviewers re-read your rebuttal. Vague answers and skipped comments get caught.
The one rule that decides whether a re-reviewer can verify your work: every reply must indicate the page and line number that cite the change in the revised manuscript, never the original.
Run an IEEE Internet of Things Journal rebuttal readiness check before you upload the revision, or work through this guide manually. For the broader cluster, see the IEEE Internet of Things Journal profile.
This page covers IEEE Internet of Things Journal (IoT-J) specifically: how its associate-editor-managed re-review changes what a rebuttal has to do, a copyable letter template, tone calibration for systems reviewers, the page-and-line rule, the typography convention IEEE expects, and the honest case where a revision still ends in rejection. It is written for the major-revision decision that lands at the 6.9-week median first decision and runs another 3 to 4 months through re-review.
What does an IEEE IoT Journal response to reviewers actually require?
An IoT-J rebuttal is a contract with the same people who reviewed you the first time. The journal runs single-anonymous review with a minimum of two reviewers, and its associate editor guideline states that in general no new reviewer is invited in subsequent rounds. So the associate editor and the original reviewers re-read your response with the first-round reports open beside them.
The rebuttal has to (1) answer every comment, (2) state the specific change, and (3) point to the exact page and line number in the revised manuscript where the change lives. Reviewers will not reconstruct your edits from prose.
Element | What IoT-J reviewers expect | What gets a revision bounced |
|---|---|---|
Structure | Letter to AE, then point-by-point per reviewer, in decision-letter order | Free-form prose merging all comments together |
Location refs | Page and line of the revised manuscript on every change | "We have updated the manuscript" with no location |
Evidence | New testbed, trace, or measurement when a reviewer asks for it | A paragraph of argument where a measurement was requested |
Baselines | The added comparison and ablation the reviewer named | "The baseline is sufficient" without running it |
Tone | Direct, calm, substantive on methodology | Defensive on cosmetic comments; arguing every point |
Typography | Reviewer text in italics, response in normal font | One undifferentiated block of text |
Source: IEEE IoT Journal associate editor guideline and author guidelines, accessed June 2026; Manusights pre-submission review observations.
The IEEE IoT Journal rebuttal letter template
Copy this structure. It satisfies the three things IoT-J re-reviewers check first: a letter to the associate editor, per-reviewer ordering, and a location on every change. Replace the bracketed parts with your own content.
Dear Associate Editor,
Thank you for handling our manuscript the manuscript title, JIOT-[number], and for coordinating the reviews. We have revised the manuscript to address every comment. The three substantive changes are: (1) we added a hardware-testbed evaluation on [ESP32/Raspberry Pi/Jetson] reported in new Section V-B; (2) we added two missing baselines and an ablation in Table III; and (3) we clarified the IoT-system scope in the abstract and Section I.
All changes are marked in blue in the revised manuscript. Below we respond to each comment point by point, with page and line numbers referring to the revised manuscript.
-----------------------------------------------------------------
Reviewer 1
Comment 1.1: "The evaluation is simulation-only and does not establish
that the method works on constrained IoT hardware."
Response: We agree. We added a prototype evaluation on an ESP32-based
testbed (8 nodes, measured energy via INA219) in new Section V-B,
page 7, lines 12 to 41, and Table IV. The measured per-inference energy
(2.3 mJ) is within 9% of the simulated estimate.
Comment 1.2: "Baselines are dated; please compare against a 2024-era method."
Response: We added [Method X, 2024] as a baseline and an ablation isolating
the contribution of the edge-scheduling step. See revised Table III,
page 6, lines 4 to 22, and the discussion on page 6, lines 30 to 38.
-----------------------------------------------------------------
Reviewer 2
Comment 2.1: "The novelty over the authors' prior conference paper is unclear."
Response: We expanded the difference statement in Section I, page 2,
lines 18 to 29, and we added the new latency analysis in Section V-C
(page 8) that did not appear in the conference version. The journal
version adds the testbed, two baselines, and the scalability study.
Comment 2.2: "Figure 5 lacks variance bands."
Response: We changed Figure 5 to report mean over 100 runs with 95%
confidence intervals (page 9, lines 2 to 6). The improvement remains
statistically separated from the strongest baseline.The three structural tokens IoT-J re-reviewers scan for are present here: the opening to the associate editor, the Reviewer 1 / Reviewer 2 split, and a page-and-line location on every action. Use the same skeleton even for a minor revision; the only thing that shrinks is the per-comment depth.
Why IEEE IoT Journal re-review changes the rebuttal math
Most rebuttal advice is written for journals where a fresh reviewer might read the revision. IoT-J is not that. Because the associate editor keeps the same reviewers across rounds, three things follow that change how you write.
First, you cannot quietly reframe. The reviewer remembers what you claimed in round one. If the abstract promised edge-latency gains and the original results omitted latency, adding a sentence will not satisfy the same reader who flagged it; you need the measurement.
Second, disagreement is read against memory. The associate editor guideline explicitly tells AEs to stay calm and give constructive explanations when a rebuttal arrives, and it lets the AE ask reviewers to soften comments. That courtesy runs both ways. A rebuttal that argues a point the reviewer already considered, without new evidence, reads as if you did not take the report seriously.
Third, the AE is a real audience, not a router. The opening letter is where you give the AE the one-paragraph summary they need to recommend acceptance to the editor-in-chief. Make the three biggest changes legible in that paragraph so the AE does not have to mine the point-by-point section to find them.
The page-and-line rule
Every change you describe must end with a page and line number that points to the revised manuscript, not the original. "We have addressed this concern" with no location is the most common reason a re-reviewer cannot verify a fix and asks for another round.
Tone calibration: how IoT-J systems reviewers read your replies
IoT-J reviewers are mostly systems-and-deployment people. They reward direct answers and precise locations, and they penalize defensiveness and hand-waving. Calibrate against these pairs.
Bad (what gets flagged) | Better (what re-reviewers want) |
|---|---|
"The reviewer misunderstood our contribution." | "We see how Section III was unclear; we rewrote the contribution statement on page 2, lines 18 to 29." |
"We believe the simulation is sufficient evidence." | "We added an 8-node ESP32 testbed in Section V-B (page 7) measuring energy and latency on real hardware." |
"This experiment is beyond the scope of the paper." | "Running on FIT IoT-LAB was not feasible in the revision window; we instead added a real-trace NS-3 study (page 8) and note the testbed limitation in Section VI." |
"We have addressed all comments." | "Comment 1.1 is addressed in Table IV (page 7); comment 1.2 in Table III (page 6); comment 2.2 in Figure 5 (page 9)." |
"The baseline we used is standard." | "We added [Method X, 2024] and an ablation in Table III (page 6) to situate the gain against current work." |
"We respectfully disagree with Reviewer 2." | "We disagree, and here is the evidence: the measured throughput in Table V (page 9) holds under the packet-loss condition the reviewer raised." |
The pattern: every "better" reply names a concrete change and a location. Disagreement is allowed when it carries evidence; what is not allowed is disagreement that asks the reviewer to take your word.
The typography convention IEEE expects
IoT-J authors should use formatting to separate the three layers of the document so a re-reviewer can navigate fast. The IEEE-Transactions convention, which IoT-J follows, is to set each reviewer comment in italic font and your response in normal font so the reader never loses track of who is speaking.
Highlight the corresponding changes in the revised manuscript in a distinct color (blue is standard) so the reviewer can jump from your reply to the edit. This is rule six of Stafford Noble's "Ten Simple Rules for Writing a Response to Reviewers," and re-reviewers under time pressure notice immediately when the document does not do it.
Readiness check
Run the scan to see how your manuscript scores on these criteria.
See score, top issues, and what to fix before you submit.
What pre-submission reviews reveal about IEEE IoT Journal rebuttals
In our pre-submission review work with IEEE Internet of Things Journal submissions, the rebuttals that draw a reject-after-revision or a second-round rejection fail in three named ways. Most of the failed revisions we see share at least one of these, and each is testable against your own response letter before you upload it. Each maps to a manuscript component the associate editor's reviewers re-check by hand.
Simulation-promised-as-testbed in the IEEE Internet of Things Journal revision. The most common pattern we flag is a rebuttal that answers a "needs real-IoT validation" comment with more simulation, dressed up as deployment. A reviewer who wrote that comment in round one is reading the same words back.
In the IEEE Internet of Things Journal manuscripts we screen, the rebuttals that survive add a named hardware testbed (ESP32, Raspberry Pi, nRF52, or Jetson-class device with its SoC, memory, and power profile stated), a public testbed deployment (FIT IoT-LAB, w-iLab. t, FABRIC), or at minimum a realistic-trace simulation (NS-3 or OMNeT++ driven by real packet traces) rather than uniform-random assumptions.
If the original evaluation was simulation-only and the reviewer asked for hardware, no rewording of the response letter substitutes for the measurement. The fix is to run the smallest credible real-IoT study that touches the contested claim, report it with measured energy and latency, and cite the new section by page and line.
Baseline-and-ablation theater in the response letter. The second pattern is a rebuttal that says the baselines are adequate instead of adding the comparison and ablation the reviewer named. IoT-J reviewers re-check the experiments section against the introduction's promises, and a response that defends a single dated baseline reads as evasion to the same reader who flagged it.
In the IEEE Internet of Things Journal revisions we review, the strongest rebuttals add the specific current-work baseline the reviewer cited, add the ablation that isolates where the gain comes from, and add variance bands or confidence intervals to the figures so the statistical significance of the improvement is established rather than asserted. A performance plot without confidence intervals is a standing invitation for the re-reviewer to doubt the gain.
The fix is to treat every baseline or ablation request as a non-negotiable experiment, run it, and point to the exact table.
Scope-defense instead of scope-repair on the IEEE Internet of Things Journal contribution. The third pattern is arguing that a generic networking, distributed-systems, signal-processing, or machine-learning contribution is "for IoT" rather than rewriting the contribution so the IoT-system specificity is load-bearing. When a reviewer flagged retrofitted IoT framing in round one, a rebuttal that re-asserts relevance without naming the device class, network topology, and operational constraints loses the same reader twice.
In the IEEE Internet of Things Journal submissions we pre-screen, the rebuttals that recover rewrite the abstract and Section I so the constraint is explicit (for example, "an in-network aggregation scheme for LoRaWAN gateways under duty-cycle constraints" rather than "a new aggregation protocol for IoT"), and they cite the revised passages by page and line.
The fix is to repair the framing in the manuscript, not to defend it in the letter, because the associate editor can still redirect a paper to a sister IEEE venue after a revision.
When to comply and when to push back at IEEE IoT Journal
Reviewer situation | Recommended response |
|---|---|
Asks for a hardware testbed or real traces where you had simulation only | Comply. Run the smallest credible real-IoT study and report measured energy and latency. |
Asks for a current-work baseline or an ablation | Comply. Add it; do not argue the existing baseline is enough. |
Requests an experiment genuinely outside the contribution | Push back with evidence: explain the boundary, add the closest feasible study, note the limitation in the discussion. |
Flags retrofitted IoT framing | Repair the manuscript scope; do not defend the framing in the letter. |
Misreads a method because the text was unclear | Accept the blame, rewrite the passage, cite the new page and lines. |
Raises a point you can rebut with a measurement already in the paper | Disagree, and point to the exact table or figure that settles it. |
Source: IEEE IoT Journal author guidelines and Manusights pre-submission review observations, accessed June 2026.
The IEEE IoT Journal revision timeline
Revision task | Typical effort | What happens |
|---|---|---|
Read reviewer reports | A day or two | Cluster comments per reviewer; identify which need new experiments |
Run requested testbed or baseline experiments | Several weeks | The real cost of a major revision at IoT-J |
Draft point-by-point response | One to two weeks | Per-comment reply plus revised-manuscript location |
Co-author and language pass | A few days | Verify every location, mark changes in blue |
Submit revision via the IEEE Author Portal | A day | Upload revised manuscript plus response letter |
Associate-editor-managed re-review | Roughly a month or more | Same reviewers re-read; AE recommends to the editor-in-chief |
Source: Manusights review of IEEE IoT Journal resubmission timelines plus the journal's published 6.9-week first-decision median, accessed June 2026.
Honest friction: when an IEEE IoT Journal revision still ends in rejection
Major revision is an invitation to re-review, not a soft acceptance, and a real share of revisions still draw a reject after revision. The associate editor and editor-in-chief make the call based on whether the reviewers' concerns were actually resolved, not on how hard you worked.
In the IEEE Internet of Things Journal resubmissions we review, the rebuttals that get rejected on the second round share a profile: they promised testbed validation and delivered more simulation, they argued with the reviewer instead of running the requested experiment, or they left one or two comments unanswered.
A SciRev community report for this journal describes a thorough process (around two reviews per round, high-quality reports, a first round near 13 weeks) that still ended in rejection, which is what a venue that reviews seriously after a hard desk screen looks like.
Two cases are worth naming. If two reviewers independently said the evaluation is not real-IoT and you cannot produce a testbed or real-trace study in the revision window, a polished rebuttal will not save the paper; consider a sister venue with a different evidence bar, such as IEEE Access for sound work or IEEE Sensors Journal for sensing-led contributions.
And if the original decision was an appeal-shaped disagreement about novelty rather than a fixable concern, a rebuttal is the wrong instrument; appeals at IEEE rarely reverse a scope or novelty judgment. Be honest about which case you are in before you spend a month on the response letter. If you are unsure whether the revision is winnable, an [IEEE Internet of Things Journal manuscript readiness check](/ai-review?
target_journal=IEEE%20Internet%20of%20Things%20Journal&source_blog=ieee-internet-of-things-journal-response-to-reviewers&primary_concern=evaluation) can separate a fixable evaluation gap from a structural scope problem.
For a manuscript-specific signal on your revised draft before re-submission, run a readiness check (/ai-review).
Last verified: June 6, 2026 against IEEE IoT Journal editorial and author pages.
Frequently asked questions
Open with a short letter to the associate editor summarizing the major changes, then a point-by-point section for each reviewer in the order of the decision letter. Quote each reviewer comment in italics, write your reply in normal font, and end every reply with the exact page and line number in the revised manuscript where the change appears. Address every point, even the ones you disagree with.
Usually yes. The journal's associate editor guideline states that in general no new reviewer should be invited in subsequent review rounds, so the same reviewers who wrote the first reports read your rebuttal and revised manuscript next round. That changes the rebuttal math: vague answers and unflagged disagreements get caught because the reader already knows the manuscript.
Yes, and they should reference the revised manuscript, not the original. The single most common rebuttal weakness we flag is We have addressed this with no location. Reviewers re-reading a revision under time pressure will not hunt for your change; give them the exact page, line, figure, or table so the fix is verifiable in seconds.
Long enough to answer every comment with a specific change and a location, which for a major revision is usually 6 to 15 pages. The length comes from substance, not padding. Reviewers in this venue are systems and deployment oriented, so each evaluation comment typically needs a new measurement, a new baseline, or a documented reason it is out of scope.
Yes. Major revision is an invitation to re-review, not a soft acceptance. A revision that promises testbed validation but delivers more simulation, or that argues with the reviewer instead of running the requested experiment, commonly draws a reject after revision. The decision rests with the associate editor and editor-in-chief based on whether the reviewers' concerns were actually resolved.
Sources
- IEEE Internet of Things Journal Associate Editor Guideline (re-review and rebuttal handling, accessed June 2026)
- IEEE Internet of Things Journal Guidelines for Authors (accessed June 2026)
- Ten Simple Rules for Writing a Response to Reviewers, Stafford Noble, PLOS Computational Biology (accessed June 2026)
- IEEE Internet of Things Journal on SciRev (review timelines, reviewer reports) (accessed June 2026)
Best next step
Interpret the status and choose the next move.
The better next step is guidance on timing, follow-up, and what to do while the manuscript is still in the system. Save the Free Readiness Scan for the next paper you have not submitted yet.
Guidance first. Use the scan for the next manuscript.
Anthropic Privacy Partner. Zero-retention manuscript processing.
Where to go next
Same journal, next question
Supporting reads
Conversion step
Interpret the status and choose the next move.
Guidance first. Use the scan for the next manuscript.