[SensorNetArch] SP final?

[David Culler]

Page 1.  First paragraph.  unifying sensornet protocol (SP) - you could 
choose to go with "unifying sensornet abstraction"

The footnote text looks bigger than the main text.  Could shrink it to 
save a tiny bit.

Page 2.  First line add "as" - layering as used
change 'must' to 'should'

page 3.  Funny punctuation ", like S-MAC, UNPF"  Perhaps comman after 
S-MAC should be a period.

Page 4 last paragraph "complete knowledge"  - drop the "complete"

page 6, last para, "use by Zigbee" should be "used by..."

page 7 second para "either are true" should be "either is true"

page 11 last para, add commas ", such as SIFT or CSMA/p*,
doesn't -> does not
drop the possessive in "neighbor's schedules"

also next para on page 12, "neighbors' "

first para in 7.2 sentence reading "reduces significant overhead" needs 
rewordng.  Perhaps "reduces state and computation overhead significantly"

second column middle of the page is also rough.  Sentence containing 
"squeeze"

Drop However in second to last paara

Page 13 "Sensor Protocol" - where did that come from?  Sensornet 
protocol, maybe.  Do you realyl want to open it like that.  Also wire 
format should probably have quotes.

Last para - drop comman after "effector networks"

add DARPA NEST, California Micro and other NSF grants to the acks.

wow look at all those refs...

Joe Polastre wrote:

> Thanks for your comments.  I've updated the document based on 1,2, and
> 4.  I couldn't find the specific reference you wanted to change in 3. 
> Can you send over some text to illustrate what you mean?
> 
> -Joe
> 
> On 8/23/05, Phil Levis <pal at cs.berkeley.edu> wrote:
> 
>>On Tue, 2005-08-23 at 16:57, Joe Polastre wrote:
>>
>>>Here's a 14-page version (we're limited by 14 pages).
>>>
>>>I think its due tonight.  Major comments, let me know ASAP.
>>
>>Looks good. Four comments:
>>
>>1) Last paragraph in left column of page 6: "Our implementation achieves
>>this through redefinition of the table entry structure..." is unclear.
>>Should say that you have to hand-tweak it, then the () followup about
>>nesC can a simple statement of how to improve it.
>>
>>
>>There are some hold-overs from older versions of the work which are now
>>contrary to it:
>>
>>2) Last sentence of first paragraph of abstract: should say it provides
>>message pool and neighbor table rather than single-hop broadcast.
>>
>>3) Third paragraph of introduction should note distinction between
>>service and interface: the former is section 2, the latter is section 3.
>>
>>4) Third paragraph of left column of 13 should return to
>>service/interface/protocol distinction: it defines the first two, which
>>may then lead to the third.
>>
>>The first paragraph of section 2 of the HotOS paper presents the
>>distinction as made by OSI:
>>
>>"At the highest level, an architecture decomposes a problem domain into
>>a set of services, which are functional components, their mechanisms and
>>their responsibilities. An architecture can also define a set of
>>interfaces to its services, which are the structures and functions
>>services expose their mechanisms with. Finally, at the lowest level, an
>>architecture can specify its protocols, which include packet formats,
>>communication exchanges, and state machines."
>>
>>Phil
> 
>>