I read the Problem draft again, and therefore have some (admittedly
belated) comments.
Section 4.1, "IP Connectivity"
If I were writing this section, I would focus on what we probably
agree are our primary objectives. (I would probably also try to
avoid specifying the solution in a requirements document). I might
write something like:
The principal motivation for this work is to seamlessly
interconnect 802.15.4 networks with IPv4 and IPv6 networks,
including the Internet.
I don't think this statement is made clearly and directly in
this document, (or the charter, the last time I looked).
The current text of this section, for the most part seems to focus
more on why IPv6 was chosen as the solution, rather than on a
strong statement that our objective is to interconnect 802.15.4
networks with IP networks. (Yes, the _last_ of the four bullets
sort of implies this, but it feels like what should be the primary
message was tacked on the end of some IPv6 justifications.)
Section 3. "Assumptions", Bullet 5.
While it isn't politically correct to say so, I believe that
there will be a device between IP networks and 802.15.4 networks
that meets most reasonable definitions of a "gateway". Nonetheless,
it is true that the use of the IPv6-like protocols that are being
discussed make the operation of this not-really-a-gateway fairly
straight-forward and transparent.
Section 5. "Goals", Bullet 2.
This would be a nice place to explain in a sentence or two why
a stateless header compression technology is needed, and why
ROHC isn't applicable.
- - - - - - - - - - -
A bunch of nits and diction complaints follow.
"Abstract"
The abstract claims that "Additional goals may be found necessary
over time and may be added to this document." I don't understand
how this document is going to be modified over time, particularly
after it is an RFC.
1. "Introduction", First Paragraph
It might make sense to include "limited computational power and
limited memory" in this list. While this is (sort of) implied by
low cost and low power, these limitations are so fundamental to the
work of the group that it might not hurt to be explicit about them
in the first paragraph.
1. "Introduction", Second Paragraph
I don't understand the term "IP and IPv6". Assuming this isn't
an editorial comment on IPv6, is this supposed to read "IPv4 and
IPv6"?
I'm not sure I like the phrase "enabling IP communications between
devices in a LoWPAN" because I assume that our real interest is
to enable IP communications between devices attached to 802.15.4
networks and IP devices on _other_ networks, (as well as intra-
802.15.4 communications).
Have we identified any items that are not "necessarily appropriate
tasks for the IETF"? The purpose of this sentence is not clear
to me. Could this sentence be deleted?
2. "Overview", First Paragraph
Yes, I know the 802.15.4 spec uses the term "relaxed throughput",
but it still seems a bit affected to me. "Limited bandwidth"
seems a bit more direct, (but I warned earlier that this is the
diction section...)
2. "Overview", Sixth Bullet
"Limited processing power, limited memory, etc." might read better
than "low processing, low memory, etc." I might also delete the
last sentence -- it doesn't really add much.
2. "Overview", Ninth Bullet
This bullet seems to munge two ideas together: that connectivity
may be unreliable and that devices may be be unreliable. The
bullet might read better if the ideas were stated separately,
or maybe if the bullet focused on connectivity rather than devices.
2. "Overview", Tenth Bullet
Perhaps, "In many environments, devices connected to a LoWPAN
may sleep for long periods of time in order to conserve energy,
and are unable to communicate during these sleep periods."
3. "Assumptions", Bullets
I might focus on the assumption that using IP technologies will
simplify the interconnection of 802.15.4 networks and IP networks.
This is sort of what the last paragraph says, my quibbles about
the claim that a gateway won't exist notwithstanding.
I don't really understand what the first bullet is trying to say.
Perhaps, it would be more clear if a few examples were provided.
I have some question about how applicable the fourth bullet is.
Will I be able to ping a LoWPAN device? Send it an SNMP GET?
(This is where I will say that it would make a lot more sense
for the we-can't-call-it-a-gateway to respond to these requests
for the LoWPAN device.)
Section 4.2, "Topologies", Fourth Bullet
The notion that many LoWPAN devices will sleep much of the time
is a very important idea. I would either make this the focus of
the bullet, (e.g., move this sentence to the beginning of the
bullet) or add a separate bullet that mentions it.
Section 4.2, "Topologies", Last Paragraph
This is a very important paragraph. Many of my comments try to
emphasize the idea that we want to seamlessly integrate 802.15.4
networks with IP networks. However, this idea currently seems
to be buried in this discussion of topologies.
Section 5, "Goals", Fourth Bullet
"Ad hoc" is two words. (OK, OK, this is pretty minor, but
ad hoc networks are so closely related to this work that we at
least ought to spell their name correctly...)
Section 5, "Goals", Seventh Bullet
This is a very interesting topic. I don't know whether we want
to suggest changes to verbose higher-layer protocols or simply
say "don't do that". (When reviewing a specification document
for a system that was going to operate in a wireless environment,
I finally gave up and simply said, "just globally replace all
instances of "XML good" with "XML bad".)
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
