Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

peter van der Stok <[e-mail]> wrote:
    > In principle the removal of paragraphs can be quite satisfactory
    > because in the restraint one recognizes the master (my translation from
    > German).  But, it makes me wonder for whom we write this applicability
    > draft.

It's written for two entities:
     1) people procuring networking (who write Requests For Proposals: RFP)
     2) people who create networking solutions (who answer RFPs)

You can't tell those groups that they need to specify some unknown, not yet
defined protocol.   It's actually against international trade agreements to
do so!

I realize at this point that it is rare to see an RFP like this, that mostly
the RFP says something like: "please provide lights for our building", and
that given that almost all solutions to date have been proprietary, that
it's not the building owner's job to decide upon a standard... but that will
change. 

    > It is quite clear that protocols exist and are used for the
    > initialization of the layer-2 security.  On the other hand, many new
    > protocols are suggested and not from an academic point of view but
    > because there is a need.  Removing the speculation means removing the
    > recognition of this state of affairs.

Of course, we can revise the document to specify new things, but that means
a new set of requirements.

    > My suggestion is that with the removal of the speculation, a caveat is
    > introduced that current text does not cover all known building and home
    > deployment cases.  Especially in connection to multicast I should like
    > to indicate that work on multicast security is needed because far from
    > solved.

The document has to specify solutions that exist;  that the current solutions
do not cover all deployment cases may be acceptable to document.  In this
specific case, we could write:
         "This document does not specify a multicast security solution.
         Networks deployed with this specification will depend upon layer-2
         security to prevent outsiders from sending multicast traffic.
         It is recognized that this does not protect this control traffic
         from impersonation by already trusted devices.  This is an area
         for a future specification."

At least we recognize and document the limitations.

    > An alternative conclusion is that current state of affairs suggests an
    > Information document.

    >> I would like prefer that this document was even more precisely about
    >> what kind of 15.4 security is being used, either directly profiling
    >> the relevant parts of the 802.15.4 specification, or by indirect
    >> reference to something that does.
    >> 
    > The draft mentions ZigBee and Wi-SUN HAN. Any additional suggestions?

Yes, it does.  Can we specify them more clearly?  I think that it would be
either Zigbee IP (-2013? is it?) *OR* Wi-SUN HAN (I have no clue about this
one).

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [