On Thu, 15 Feb 2007, The IESG wrote:
The IESG has received a request from the IPv6 over Low power WPAN WG
(6lowpan) to consider the following document:
- '6LoWPAN: Overview, Assumptions, Problem Statement and Goals '
<draft-ietf-6lowpan-problem-07.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2007-03-01. Exceptionally,
comments may be sent to iesg@xxxxxxxx instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-07.txt
Sorry for slightly missing the LC deadline.
6. Low cost. These devices are typically associated with sensors,
switches, etc. This drives some of the other characteristics
such as low processing, low memory, etc. Numerical values for
"low" elided on purpose since costs tend to change over time.
==> what kind of 'switch' do you have in mind? How does that
participate in a _personal_ area network?
As a side note, there appears to be nothing in the requirements that
relates directly to the 'personal' of personal area network. For
example, there are no assumptions about the maximum diameter of the
network.
Are you really specifying Low-power Wireless Area Networks rather than
LoWPANs? Are there any goals, problems or assumptions relating to
'personal' that one should be aware of? Or should you just remove
'personal' from the text(s)?
4.2. Topologies
==> I was a bit disappointed as I saw no mention of securiry wrt
routing in the mesh topology. It isn't mentioned in the later part of
the text as well. E.g., how do you prevent malicious nodes from
joining the network and doing e.g., MiTM attacks by posing as routers?
Are you assuming that the link-layer security will keep unauthorized
nodes away from the LoWPAN network? If that is the assumption, more
emphasis might be needed on how to actually configure the link-layer
keying. Based on current text it's not clear if configuring keying in
all the nodes is operationally feasible or even possible.
4.3. Limited Packet Size
Applications within LoWPANs are expected to originate small packets.
Adding all layers for IP connectivity should still allow transmission
in one frame without incurring excessive fragmentation and
reassembly. Furthermore, protocols must be designed or chosen so
that the individual "control/protocol packets" fit within a single
802.15.4 frame. Along these lines, IPv6's requirement of sub-IP
reassembly (see Section 5) may pose challenges for low-end LoWPAN
devices that do not have enough RAM or storage for a 1280-octet
packet.
==> I wonder what the last sentence implies. Given that the
-format specification still requires the 1280 byte IP MTU, the RAM
requirement was probably not blocking here. Rewording this slightly
due to how -format ended up being might be useful.
4.4. Limited configuration and management
As alluded to above, devices within LoWPANs are expected to be
deployed in exceedingly large numbers. Additionally, they are
expected to have limited display and input capabilities.
Furthermore, the location of some of these devices may be hard to
reach. Accordingly, protocols used in LoWPANs should have minimal
configuration, preferably work "out of the box", be easy to
bootstrap, and enable the network to self heal given the inherent
unreliable characteristic of these devices. Network management
should have little overhead yet be powerful enough to control dense
deployment of devices.
==> no or very little configuration, yet network management should be
powerful enough to control a huge number of devices? How do you
manage the authorization of network management then, i.e., who is
allowed to control the devices?
I'm somewhat surprised that you do not mention overcoming (initial)
configuration tasks (including but not limited to network management)
as an item under Section 5.
For network layer security, two models are applicable: end-to-end
security, e.g. using IPsec transport mode, or security that is
limited to the wireless portion of the network, e.g. using a security
gateway and IPsec tunnel mode.
==> it might be useful to mention how header compression relates to
IPsec. Are there problems if both are applied? If non-NULL IPsec
transform is used, can header compression be used at all?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf