[SensorNetArch] Edits

[Rodrigo Fonseca]

  I agree with Prabal that section 2 could have the new order of paragraphs.

  A very minor typo, S3-P2 (missing an s)

   Instead, a single, simple interface needs to be ... that facilitate*s*
  in-netowk processing ...

  Three comments on Section 4:

  - change "We discuss two abstractions, the multihop" to
  "We discuss two abstractions as examples, the multihop..."

  The two abstractions -- multihop protocol layers and cross-layer power
  management -- should be introduced as examples. The way it's written may
  give the impression that they are the only important ones.

  -In 4.1 The fact that the In-NetworkStorage is above the two protocols
  in the figure, but is apparently described at the same level as them in
  the text ("Three basic abstractions lie above SP..."), is confusing.
  Also, in this paragraph the terms layers and components, and how
  applications relate to and use them is very vague.

  *There is also a typo: lies --> "lie" in the same sentence.

  - In 4.2, second column, there's a paragraph starting

  "A fundamental requirement for building name-based protocols is the
  formation and maintenance of a connectivity graph."

  I tend to disagree with this statement (the "fundamental requirement"
  part of it). The fundamental condition is the establishment of a
  *gradient* towards a name. The connectivity graph is important in many
  cases, but there can be *opportunistic* routing schemes which are
  name-based, and do not require any maintenance of a set of links.

  No further comments at this time.

  Thanks,
  Rodrigo


> 
> 
> prabal at eecs.berkeley.edu wrote:
> 
>> Just a few comments for sections 1-3.  I've also attached the version 
>> of the PDF that I used in case these references have changed.  Let me 
>> know if you need any clarifications.  Looking pretty good.  Let me 
>> know if/when we should review section 4.
>>
>> - Prabal
>>
>> S,P,L = section/para/linenumber
>>
>> S1,P1,L1: Why is
>>   "Wireless Sensor Networks"
>> capitalized?  Should the WSN acronym be introduced here or at least 
>> the ("sensornets") term which is used later in this paragraph?
>>
>> S1,P1,L13: Consider changing "where" to "in which"
>>
>> S2,P1,L15: The following sentence:
>>
>>   "Thus, the traditional division of application, operating system, 
>> and network has been opened to re-examination"
>>
>> could (1) become the beginning of a very nice paragraph, (2) be 
>> changed slightly to something like:
>>
>>  "Thus, the traditional division of application, operating system, and 
>> network has been blurred."
>>
>> and (3) be a *great* segway for launching the whole point of this 
>> paper (it kinda does that already, but it could worded more strongly): 
>> that existing applications have blurred this boundary precisely 
>> because there is no architecture and the whether and the degree to 
>> which this blurring is necessary (e.g. rich interfaces) but not 
>> desirable (e.g. abstraction) remains to be discovered.
>>
>> S2,P1-P3: Consider changing the paragraph order 1,2,3 -> 2,3,1 since 
>> what is currently P1 ends with the perfect sentect for the next section.
>>
>> S3,P2,L3: I don't follow the claim here; are we claiming that a narrow 
>> waist *can* exist, or that it *should* be the best-effort, single-hop 
>> broadcast, or *both*.  I don't disagree with the first claim, or at 
>> least I'm willing to suspend disbelief long to hear you out, but the 
>> second claim hasn't been sufficiently well motivated to be credible at 
>> this point in the paper.
>>
>> S3,P2,LastLine-1: It's not clear to me what "packet boundary" mean in 
>> the following sentence:
>>   "...how functionality divides across the packet boundary is a key 
>> question."
>>
>> S3,P3,L1: There seems to be conceptual jump between SP as a protocol 
>> (S3,P2) and the interface to SP (conceptual and API?)
>>
>> Page 3, Line 2: "include" should be "including", I think.
>>
>> Page 3, Line 8: consider "expose" rather than "project"
>>
>> Page 3, Para 2, Line 10: there's a "to" missing after "competitive"
>>
>> Page 3, Para 3: Should the idea of resource reservation (e.g. the MAC) 
>> be introduced?  Seems like it might be an obvious extension of the 
>> concepts presented.
>>
>> Page 3, Para 4: The modifier "address-free" has not been introduced 
>> previously in this paper (at least not that I noticed).  Some readers 
>> (including me) might assume that broadcasts usually are sent to a 
>> broadcast address. If this is not case, need to mention before 
>> introducing this term.
>>
>> Page 3, Para 4: Seems like mentioning the kind of "annotation" that 
>> Click supports is a good analogy to the attaching metadata problem.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SensorNetArch mailing list
>> SensorNetArch at Millennium.Berkeley.EDU
>> http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/sensornetarch
> 
> 
>