Timothy,
The WG last call on the problem statement document has long since
closed. That said, I think that a few of the editorial nits that you
point out could and should be addressed, though we need input from the
rest of the group as to which of your comments should be "fixed".
geoff
On Mon, 2006-11-06 at 18:38 -0600, 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.)
>
> 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
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
