All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
Congratulations, the revised version is satisfactory and recommended for publication.
[# PeerJ Staff Note - this decision was reviewed and approved by Vicente Alarcon-Aquino, a PeerJ Section Editor covering this Section #]
The style and language of reporting has been improved. Changes suggested by the reviewers have been incorporated.
There was no issue in the experimental design. I asked for some clarifications and improvements which have been incorporated.
No issue seen.
All my concerns have been addressed.
The reviewers have recommended minor changes to the submitted manuscript. Please see the reviewers' comments and revise the manuscript accordingly.
Also, consider the following changes in the revised version of the paper:
- Add a related work summary table comparing the core available approaches in terms of the multiple aspects.
- The discussion of the related techniques is very brief. Extend the discussion with more detail about the methods' working semantics along with the limitations.
- Extend the implementation section with more details about the implementation.
The paper is written in clear professional English.
The literature review is comprehensive.
The results reporting is professional.
The experiments and results looks valid.
The experiments and results looks valid.
The proposed method is used to successfully uncover real vulnerabilities in Redis and Memcached.
A weakness of the proposed method is that it seems it's limited to in-memory data-stores. Can it be generalized to other softwares whose behavior depend on different dataset/states?
I'm not an expert on fuzzing so the review is mostly about overall writing.
A well written paper. The research is ambitious and correctly presented.
With reference to the flow/ readability of the research it is not very welcoming for the reader who is just entering into the domain. This is a point the authors can consider for improving the overall readability.
Having said this I will recommend that the literature review be extended to incorporate a breadth of knowledge.
Also highlight the known downsides of using fuzzing. The vulnerabilities being discovered through the method can also be listed rather than being placed within the text.
The experimental design is correct and appropriate to the research.
Although I will ask that the authors have mentioned a pretty high time requirement which is expected from fuzzing based implementation. This point can be discussed further and the underlying reason highlighted.
The comparison of the work in textual form again does not make an impression. Authors can explore how comparative analysis can be improved for readability.
Minor Revisions suggested.
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.