On Wed, 2007-03-07 at 08:07 +0200, Pekka Savola wrote:
Hi,
On Tue, 6 Mar 2007, Geoff Mulligan wrote:
You question about switches does point to an overloaded term. In that
particular paragraph the "switches" we are talking about are electrical
switches, as in light switches, not network switches. We'll fix the
wording.
I guessed as much, which is what triggered me to wonder about the use
of the term 'personal' as I don't think an electrical switch is
typically carried in your PAN :-)
The reason we use the term personal area network is that it is the
industry term used for 802.15.4 networks. I agree that these devices
are not "personal", but it is a nomenclature that we are stuck with by
the IEEE.
If you don't want to drop 'Personal' from the used terminology, I
would suggest considering adding a sentence or two in Introduction of
all relevant documents to make it clearer that the IETF has designed a
generic solution which also applies outside of PANs. The IETF
specifications as far as I can see are not restricted to 'P' in 'PAN'.
(If you consider assumptions and possible security tradeoffs this may
have good and bad consequences.)
I don't particularly like the term PAN applied to RF networks that are
not "Personal" but we are using the term from the RF platform where we
are directing these documents - IEEE 802.15.4 - "Part 15.4: Wireless
Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks (LR-WPANs)" and this is the
relevant document that we did reference. While I might prefer to use the
term "Premise Area Network" this would be confusing as it isn't the term
used for 802.15.4 networks.
We did not address the security of underlying mesh network because we
have not yet defined that layer yet. We are working with MANET to
define that and the security for the mesh would be addressed in that
document. It was not germane to the format/adaptation header.
To you question about network management - again this document is about
the format and header encoding only. Network management and security
will need to be addressed by a future 6lowpan management or 6lowpan ops
document.
I'm not sure whether I agree. We're talking about a problem statement
draft. I'd agree that network management is probably outside the
scope of draft-ietf-6lowpan-format. It seemed that the network
management goals could not be fulfilled without compromising other
goals (easy or zero configuration), raising a doubt about the
feasibility of the goals.
I don't agree. I think that we can build managed networks that also use
"zero conf". I don't think that these two goals are at odds and that is
why we put them in the problem statement, so we would be reminded that
we need to build a solution that is manageable and still easy/simple to
install.
Even if NM doesn't need to be addressed in 6lowpan-format, I think
(operational) security should be. The key questions (IMHO) here are,
'Are the security mechanisms specified by IEEE and IETF good enough
that using them is feasible in real life? Will they get used?' So
far, the document doesn't give me an assurance that the answer to
either is 'yes', and hence it leaves me little to use when trying to
figure out whether the security model of 6lowpan design is adequate,
and consequently, whether the IP specification is complete or not.
I'm not sure if you are referring the to format document or the problem
statement document here. From my understanding the problem statement
document is not supposed to be defining the solutions - it isn't a
standards doc and security mechanisms are outside the scope of format
document since it is just defining a header encoding scheme to carry IP
over 802.15.4 frames. It doesn't preclude the use of IPsec or some
other yet to be defined security protocol. If there is a mesh network
layered under 6lowpan that document will need to define the security
used to protect the routing in the mesh. If we are discussing what
devices may join a network that will need to be specified by the network
management document.
geoff
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf