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

Michael Richardson <> Wed, 15 April 2015 16:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5FD741ACD44; Wed, 15 Apr 2015 09:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dstuCiVf3iwV; Wed, 15 Apr 2015 09:02:21 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D1311ACCE0; Wed, 15 Apr 2015 09:02:21 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 4E08A2009E; Wed, 15 Apr 2015 12:13:28 -0400 (EDT)
Received: by (Postfix, from userid 179) id 3BD2E63B76; Wed, 15 Apr 2015 12:02:20 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 29444636B6; Wed, 15 Apr 2015 12:02:20 -0400 (EDT)
From: Michael Richardson <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 15 Apr 2015 12:02:20 -0400
Message-ID: <>
Archived-At: <>
Cc:, Routing Over Low power and Lossy networks <>,, The IESG <>,,,
Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Apr 2015 16:02:23 -0000

peter van der Stok <> 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

    > 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

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [