Re: [Fwd: Fwd: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, Assumptions, Problem Statement and Goals) to Informational RFC]

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.)

> 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.

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.

-- 
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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf