[6lowpan] draft-brandt-6man-lowpanz as a new 6man WG document

Carsten Bormann <cabo@tzi.org> Sat, 09 March 2013 18:16 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BE05321F86DD; Sat, 9 Mar 2013 10:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E19cRHFg0C2K; Sat, 9 Mar 2013 10:16:54 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C083D21F86D9; Sat, 9 Mar 2013 10:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de []) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r29IGp9b021967; Sat, 9 Mar 2013 19:16:51 +0100 (CET)
Received: from [] (zoo.informatik.uni-bremen.de []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1AFAE3E2B; Sat, 9 Mar 2013 19:16:48 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD1D1733EA@cph-ex1>
Date: Sat, 09 Mar 2013 19:16:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B28B2A3-2AAE-4226-A442-6892FA2D9C5F@tzi.org>
References: <03F31C213F2C6941BFDDBB4336E9E6CD1D1733EA@cph-ex1>
To: Anders Brandt <Anders_Brandt@sigmadesigns.com>
X-Mailer: Apple Mail (2.1499)
Cc: "6lowpan@ietf.org" <6lowpan@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: [6lowpan] draft-brandt-6man-lowpanz as a new 6man WG document
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Mar 2013 18:16:54 -0000

Here's my review of draft-brandt-6man-lowpanz-00.  This is a worthy
addition to the collection of IP-over foo documents, and I think it
properly positions itself in the 6lowpan family of
IP-over-constrained-node-network specifications.  With one exception:

I'm not sure how this document positions itself with respect to ND.
It says it tries to parallel RFC 4944.  4944 has been updated by RFC
6775.  Is this document thus also referencing 6775?  There is also an
obscure reference to a section of 4861.  Is the intention maybe that
4861 be used unchanged?  If yes, how does this mesh with section 3.2?

My other technical problem is with section 3.4.  I don't think an
IP-over-foo document is the right place to change the IP service
model.  Besides, this kind of indication may be available about the
first-hop link, but what about mid-path?  On the socket interface, it
is hard to do a MUST here if you then don't say how it should look

More on the editorial level:

I'm not happy with the "mission-critical" wording, and also not with
the SHOULD.  How about:

   The network key is intended to address security requiments in
   the home at the normal security requirements level.
   For applications with high or very high requirements on
   confidentiality and/or integrity, such as door locks and meters,
   additional application layer security measures for end-to-end
   authentication and encryption will need to be applied.
   The availability of the network relies on the security properties
   of the network key in any case.

What does "mapped into restricted space" mean?

Grüße, Carsten