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

From: Carsten Bormann <[email-masked]>
Date: Sat, 9 Mar 2013 19:16:44 +0100

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

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

---

From: Zach Shelby <[email-masked]>
Date: Fri, 15 Mar 2013 12:26:40 -0400

I have also reviewed this draft, and am definitely supportive of it moving forward as a WG document. I agree with Carsten's comments, especially with regard to 6LoWPAN-ND. I understand that an update is already in progress to address those comments.

In addition, I found Figure 4 in Section 5.3 to be confusing at first. It should be clarified that this is a G.9959 link-layer address. 

Since this is a less widely known link-layer, a couple examples would not hurt as to the structure of the MAC framing with the address mapping defined in Section 5.3 for both unicast and multicast addresses.

Regards,
Zach

On Mar 9, 2013, at 1:16 PM, Carsten Bormann <[email-masked]> wrote:

> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Mar 2013 12:32:47 -0400

> In addition, I found Figure 4 in Section 5.3 to be confusing at first. It should be clarified that this is a G.9959 link-layer address. 

Actually, we had an off-line discussion that including the HomeID here would be akin to including the PAN-ID in Figure 7 of RFC 4944.  We didn't do that at the time, and we didn't find a good reason to do that now.  So what should remain is the 8-bit NodeID.

Grüße, Carsten