Tim,
I agree with Geoff's comments; we are a bit late with making major
changes here.
Let me go through your comments point by point.
(Chair hat off.)
On Nov 06 2006, at 16:38, Timothy J. Salo wrote:
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.)
IPv6 really needs to be motivated in the problem document.
Re IPv4: we have a clear charter to look at IPv6.
I don't think the proposed direction of change would lead to
consensus quickly.
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".
In the original, 1974 sense: Yes (we now use the term router).
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.
Routers today do have more functionality than they had in 1974. This
does not make them mysterious gateway devices, just function-ful
routers.
We do want to avoid the "gateway" in the sense that every application
upgrade requires changes to the gateway.
I think this is what bullet 5 says.
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.
Now you are in solution space.
The requirement is:
1) header compression
2) limited memory requirements.
In solution space, this leads to stateless HC as the immediate
solution, with future enhancements possibly using stateful for things
like TCP (which may or may not look similar to current ROHC profiles).
- - - - - - - - - - -
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.
Good catch.
I propose we strike this sentence now.
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.
The intro need not necessary spell out the entire situation, but I
agree that it would be good to add this.
Note that the sentence is about "IEEE 802.15.4 devices", though,
which is really a statement about the radio, while your comment is
about the device as a whole. So this would be a new sentence about
the expected characteristics of the devices.
1. "Introduction", Second Paragraph
I don't understand the term "IP and IPv6".
This does sound strange.
Assuming this isn't
an editorial comment on IPv6, is this supposed to read "IPv4 and
IPv6"?
No. This was meant to say "IP in general and IPv6 in particular".
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).
So, maybe replace "between" with "with"?
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?
The sentence could be improved. The intention is to say that not all
that needs to be done for "enabling..." can be done in the IETF, so
we need to focus on the problems the IETF can work on.
2. "Overview", First Paragraph
Yes, I know the 802.15.4 spec uses the term "relaxed throughput",
No, not the throughput is relaxed, the requirements are.
Sentence can stay as is.
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.
I find it useful to remind readers that Moore's law does apply.
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.
In the old Internet, the assumption was that devices were allowed to
fail, but shouldn't too often.
In a LowPAN, the tradeoffs shift towards unreliable devices -- for
the purposes of LowPAN, it does not make a big difference whether
somebody steps on it or it just loses connectivity.
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."
Good new text.
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.
It is trying to say that IP is already available in most
environments, so it helps to use it.
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.)
The intention is that the LowPAN devices are IP nodes, with all that
implies. A "gateway" that "helpfully" generates fake ICMP replies is
not always going to help. (But, yes, optimizations are possible.)
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.
I read this bullet as saying exactly that.
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.
Actually, we integrate them *into* IP networks.
(This is a BIG difference.)
However, this idea currently seems
to be buried in this discussion of topologies.
Yes, again, if we had lots of time and editorial manpower, we could
make this a better document.
But the consensus of the WG is appropriately caught.
Section 5, "Goals", Fourth Bullet
"Ad hoc" is two words.
I'd prefer Ad-hoc (still two words) in the adjective position.
(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".)
True, this is not something the format document can do on its own.
Further work will be required, and this may take both forms
(simplifying or replacing existing protocols).
I agree this bullet is rather nebulous, but so is our understanding
of our goals in this space.
In summary, I think there is some good editorial input here (thanks
Tim!), but I don't see any reason to reopen discussion on existing
consensus.
Depending on how we proceed with the most recent input on the format
document, we may have time to incorporate that input.
(Chair hat on.)
I would prefer to do this in a way that does not require a new WGLC
(i.e., editorial only).
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
