Guest Editor: Series, Automotive Networking Comments to the Author: The revised manuscript is much improved -- with the more balanced presentation and the appropriate new title. These reflect the overall review comments on the original version. Please make change to address the comment regarding the exposed / hidden nodes in the final version. Reviewer: 4 Comments to the Author The manuscript gives a technical overview of MAC requirements and major existing MAC techniques for V2V communications in support of safety and non-safety applications. The authors highlight key differences between MAC for V2V communications and MAC for MANET, and provide valuable insights on promising approaches as well as open technical challenges towards achieving a practical MAC for V2V communications. The revised manuscript has adequately addressed the review comments of the initial version; the revised version reads well. This reviewer has one comment that requires the authors to address. In Section IV.1 - The exposed node-free nature of the CCH, the authors are vague on the reason(s) why the exposed node does not exist in the vehicular context. This is one important aspect; the authors are urged to provide a stronger support to this point (than the current version) -- perhaps adding one or two new sentence(s). This will help the readers of the IEEE Communications Magazine to clearly see why a classical trade-off (hidden vs exposed nodes) fades away in the vehicular context. Reviewer: 2 Comments to the Author The new title is very confusing to reviewer. I didn't know it's a revised paper reviewer until I opened the file and scrolled down to the 2nd page. One obvious mistake in this revision is that the first page uses the new title, but the title of the paper on page #2 is still the old one. For me, the new title is confusing and information-less. If authors believe their research is solid and true, why would they change their title, which gives readers a non-related aspect of the contents? Serious researchers must have faith on their research work. What they need to do is not to change the title, but to add/modify contents to try to show peers the novelty and the validity of their research. One last thing, if authors made any changes, it would be a good practice to highlight the changes. This way, it would be easier for peers to pick up the updates and make decision. Reviewer: 3 Comments to the Author The authors made a very thorough job in revising the paper based on the various reviewers' comments. The paper has surely improved in terms of organization and, as a consequence, ability to convey a constructive message and very useful insights to the VANET community. I have no other concerns, for me it is a clear accept at this stage. *********************************************************************************************************************************************************************************************** Comments for the first submitted version *********************************************************************************************************************************************************************************************** Guest Editor: Series, Automotive Networking Comments to the Author: The manuscript covers an important aspect of VANET and provides many excellent insights. It has the good potential to become a timely contribution to the readers of the IEEE Communications Magazine. The authors are therefore strongly encouraged to revise the manuscript according to reviewers' comments -- particularly in terms of the presentation style and structure. Reviewer: 1 Comments to the Author This paper is a really interesting one, which is neither a technical paper nor a survey/challenging paper. Essentially, it summarizes all the possible "mistakes" made by other researchers in MAC layer VANET design and authors conducted a reasonable discussion on each of them. Though interesting, this paper might be quite controversial, due to (1) lack of technical validation of what is "right" and what is "wrong" and (2) researchers with different viewpoints could have a year-long debate about this issue. Particularly, the key topics mentioned in this paper -MAC layer unicast is used on the control channel -Beaconing is overhead -Beaconing is just broadcast -Average MAC delay is essential to measure -Applicative throughput is an important metric -The control channel needs solutions for internal contention -Collisions can be detected -The balance between hidden and exposed nodes should be found -An increased contention window cannot sustain the delay requirements -The MAC layer has the choice between multiple data rates/modulations -Dissemination of Decentralised Environmental Notifications through multi-hop messaging is necessary -The DENs are uniformly distributed in the entire network Many of them are quite interesting to this reviewer who is working on this field. Among these, some of lessons gave good insights that this reviewer has not considered in the past, which is a good contribution of this article. However, this article could be a good article for ACM CCR-type of publication given its unique style and nature. For a scientific article published in IEEE comm mag, this paper needs a number of improvement before it could be accepted - to quantify the lessons and provide solid technical evidence about the "right" approach; - many of issues are still hard to make the final conclusion. It might be too early to claim which approach is 'right' since we (our society) only have very preliminary understanding of this issue; it will be pre-matrure to claim either way is the "right" way; - to objectively lay out the reasons that the other school/camp holds and carefully discuss the implications of the thought from both schools. Generally, this is an interesting paper that authors should consider a few rounds of iteration/refinement to improve its quality/depth, so that society might benefit from it. Reviewer: 2 Comments to the Author I think the authors did a good job on researching, analyzing, and summarizing the common misconcepts, including those important ones about average thruput, delay, and the usage of beaconing. This paper serves as a good alert to all the VANET researcher and could trigger reflection on what has been done on design and analysis of VANET MAC. A suggestion to the author: it might be better to summarize/categorize all the misconcepts in the introduction section so that common readers can easily establish a more systematic view of the issues. Reviewer: 3 Comments to the Author Despite the very questionable tone of the start and end, which definitely needs to be revisited, and despite the lack of novel technical material (anyway not really expected in a magazine publication, so minor issue), the limited support in some of the claims brought about, and the perhaps too "flat" organization of the paper which weakens some important points (see detailed comments next) this is a paper that IMHO is worth disseminating. Indeed, the paper provides a critical analysis of what should, and especially should not, be the assomptions at the basis of MAC protocol and MAC functionalities design in VANETS. In its development, the paper is rich of interesting insights, and in many cases it "opens the eyes" on some facts that should be obvious, but have been neglected by part of the VANET community. In essence, the discussion carried out in the paper is definitely worth to be disseminated across the vanet community, and may contribute in better focusing future research efforts on "real" problems. This said, IMHO acceptance of the paper should be conditioned to a revision (anyway quite easy and mostly related to presentation, this explains my accept with minor revision rating) addressing the following three issues. 1) calm down the tone of the paper. The paper starts (and ends) with a very strong attack to part of the VANET community, using very strong words such as "irrelevant or unclear results", "incorrect/wrong assumptions", "misconception", etc. Now, I understand the genuine spirit of the authors, and I may also have the same position in most of their claims! But the actual content of the paper does not support such strong claims. Saying that something is wrong requires overwhelming quantitative evidence rather than an opposite position which, although agreeable and very reasonable, in many cases it remains "just" an opposite position, not accompanied by strong and uncontroversial evidence. Indeed, the obvious and trivial recommended fix is to smooth such introductive position and transform the paper from a criticism to an analysis: attack the community with your arguments (which are good, and are what a reader wahts to get out of a paper) rather than with words! 2) Give more structure to the paper. Section III, the core of the paper, is organized in a flat manner, with a list of (claimed to be) unsupported assumptions and the relevant author commentary. As a result, some of the more sound arguments brought about during the discussion are scattered around and somewhat repeated, as, indeed, they do affect many of the listed assumptions. This IMHO weakens the sting of the paper. I believe that the paper might have a much stronger impact if these arguments, and especially the most powerful ones such as the broadcast nature of the CCH, the expiration-prone nature of the CAMs, the need and emergence of a facility layer and how this changes the rules of the game, which dynamics for DENs (very interesting discussion), the poor gray-zone-rich channel, were more clearly stated as heading sections. Again, what I'm suggesting is to transform the paper from a list of randomly listed criticisms to an indepth analysis paper. The material is already all there and it's just a matter of organization. A possible structure could be in three steps/sections: - these are the facts, along with the relevant evidence - from these facts these are the issues that we believe are worth of more investigation - again from these facts, these are the issues that we believe are worth less investigation (and here you can unleash your criticism) Up to you to take it or drop it - but IMHO if you take it I believe your impact will be much stronger. For just one among many examples in your paper, take the section "average MAC delay is essential to measure". As a reader I'd not be nearly interested in reading further. We well know how our scientific world goes (like it or not), and that PhDs or promotions require to publish some yet-another-802.11p-delay-analysis. So no surprise that, to justify such works, there must be somewhere the claim that delay is essential (the world is full of introductions that tailor a problem over an available solution...). But what is the interesting message here is the CAM lifetime dynamics, which is very unfortunately buried in the text and across sections: put it at the front! And be immediately constructive and explicit in mentioning which metrics are worth more attention! 3) if/when possible, try to support your points with more quantitative evidence. For instance, I intuitively agree that safety messages are broadcast, but can you raise some facts or analyses or agreed standardization requirements that say so? Also, I fully agree that shrinking CWs is a nonsense, but again I suggest to show this with facts or prior sound studies. FYI, a good example of duly supported section is the one on multiple data rates, where indeed [14] is a convincing and credible work in a tier 1 conference, which brings plenty of evidence to your arguments. Finally some punctual comments on the section "collisions can be detected". This is by far the least convincing section in the whole paper, very handwaving and stretched, and your arguments are quite weak and far from discouraging work in this area (the ambiguity about the loss cause of a packet is a well known issue we lived for decades with, but by itself did not discouraged significant work). And privacy is not a blocker by itself - solutions to protect sequence numbers may be everntally envisioned (e.g. by masking them - although this is not a good example here, and I don't know a ready-to-use privacy solution for the VANET case, at least permit me to mention that other systems addressed this problem, e.g. the UMTS standardized AKA uses an anonymity key to mask Sequence numbers, etc).