1. Rating
   Rate the paper in the following categories (For each category,
   choose a one numeric rating)
       
   Overall grade (overall, how do you rate this summary paper?)
      5: Excellent

   Language (how fluent is the language, did you understand what this 
   paper is saying?)
      4: Very good

   Technical quality
      5: Contents are completely correct. There are no errors. It corresponds
         information on the source material. 

   Editorial quality
      4: Mostly understandable, some improvements identified below

   Confidence (how confident are you about this review?)
      3: I have good or expert level knowledge of this topic

2. Detailed comments

   Provide detailed written comments on the paper.  In general, your
   main aim as a reviewer is to help improve the paper. Be as specific
   as you can when you point out errors or problems. Suggest concrete
   improvements whenever possible.

   Your review should cover the following three aspects.  Use the
   suggested guidelines in composing your review for each aspect.


   The overall quality of the paper and the talk is very good. Some
   minor editorial comments follow. Hope I'm not too pedantic here but I thought I
   should try to use the chance to provide some feedback.

   - This sentence confused me: Page 1, end of the first paragraph of Section 2:
     "In the second step, nodes that have requested data, send back data after
     receiving the request." Shouldn't it read more like: "In the second step,
     nodes that have received data requests, send back (the sensed) data."
     or something like that? I mean the nodes gathering the data first receive
     a request and then "fulfil" the request by sending their data.

   - Section 2.1, second paragraph, another confusing sentence, probably a
     simple typo: "This occurs when a node receives the same message (!)for(!)
     several neighbours". Should it be "from several neighbours"?

   - Section 2.3, SPIN. That question was clarified during the talk,
     maybe it could also be clarified in the paper: Also neighbouring nodes
     that are not "interested" (in terms of not having previously sent a REQ
     message) forward an ADV message, so that these are flooded in the network.
     However, there is this (in my opinion slightly weird as it's unclear
     how its value should be determined) energy threshold that possibly
     prevents them from doing so.

   - Section 2.4, cost-field-approach. What was unclear to me and got clarified
     during the talk: As compared to using a standard routing protocol,
     one avoids the introduction of node identifiers by letting intermediate
     nodes compare the sum of the current cost value in the packet and its
     estimate with the total cost. One other question that comes up: Is it
     possible (e.g. having the same local cost estimate) that one message
     gets forwarded along two different paths when the shortest path cost is
     not unique? E.g. route message from D to A, gets duplicated at D. 

                    D
                 1/  \1
                  B   C
                 1\  /1
                    A
     That problem might not necessarily show up using a (standard) routing protocol,
     same problem as flooding.

   - Section 2.4, cost-field-approach, was clarified during the talk: A "fixed" value
     does not mean that a node would never forward ADV messages after its own timer has
     expired that contain a shorter route from the node to the originator.

   - Section 3.1: "While direct transmission is a simple method, it is also very ineffective."
     I would consider "inefficient" to be more appropriate here, question of taste.

   - Section 3.3: General comment:
     1. I would consider using "number" for countables and "amount" for noncountables, e.g.
        "Sensor networks contain (a) large (!)number(!) of nodes that collect some kind of data, for
         example (-) temperature or (-) air pressure, from the environment". "The (!)number(!)
         of nodes in sensor networks can be several orders of magnitude (!)larger(!) than
         in ad hoc networks". "PEGASIS aims to..minimize the (!)number(!) of messages..".
        "number of hops", etc.

     2. There are a couple of cases where I would put an "a" or "the" in between some words,
        but that's my personal opinion:
        E.g.: "In (!)the(!) direct transmission method.." "..,thus (!)the(!) amount of energy..",
        "(!)The(!) binary scheme..", "In the figure, (!)the(!) numbers on the links indicate (!)the(!)
        cost of the link, and (!)the(!) back-off timer parameter $\gamma$ is set to 10."

        Some others I would leave away, e.g. "where N is the number of nodes", "based on some metric
        like delay.", "for example temperature or air pressure"