Re: [6lo] draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)

Hi Richard and all,

ZigBee NAN uses IEEE 802.15.4 security suites, but based on IEEE 802.15.4e-2012 ones which allows CSMA MAC to use 5-octet frame counter.

As far as I understand, IEEE 802.15.4-2006 (used by ZigBee IP), IEEE 802.15.4e-2012 and IEEE 802.15.4-2015 use slightly different auxiliary security header formats.

Having said that MLE may need different security suites identifier values among those different revisions/amendments of IEEE 802.15.4.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Richard Kelsey
Sent: Friday, April 01, 2016 9:01 PM
To: Gabriel Montenegro; consultancy@vanderstok.org
Cc: robert cragie; 6lo@ietf.org
Subject: Re: [6lo] draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)

I can update section 4 to match the changes in the abstract.

There are three standards that I am aware of that use MLE: ZigBee IP, ZigBee NAN, and Thread.  I am familiar with how it is used in ZigBee IP and Thread; I know nothing about ZigBee NAN other than it adds some extensions to what was done in ZigBee IP.  Thread adds a different set of extensions.

The best way to make different versions distinguishable would be to use the "security suite" identifier that is at the start of each message.  ZigBee IP used 0 for secured messages and 255 for unsecured ones.  Thread only uses secured MLE messages and might (I can't speak for them, but I can ask) be willing to use a value other than 0 for the "security suite".  I don't know what the status of ZigBee NAN is.

As for the IANA assignments, if the "security suite" is repurposed as a protocol version, that could remain as per IETF Review.  Each separate protocol version could have its own set of assignments on a "Specification Required" basis.

                                  -Richard Kelsey
________________________________________
From: Gabriel Montenegro [Gabriel.Montenegro@microsoft.com]
Sent: Wednesday, March 30, 2016 2:53 PM
Subject: draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)

<WG chair hat off>

After Peter's review the abstract's summary of MLE's capabilities was modified. However, section 4 repeats the old language. Suggest aligning with the revised language in the abstract.

Furthermore, I'd add the clarifications along the lines of what you suggest for the 3 capabilities, namely:

 - on capability #1: This is the primary purpose for MLE.
 - on capability #2: This could be done in lots of ways.  ZigBee IP happened to use MLE.  Removing this functionality would not affect the rest of the protocol.
 - on capability #3: is an optimization to make 1) more efficient.  It isn't strictly necessary.

I'm a bit concerned about the lack of clarity in terms of applicability. For example, you say:
" The draft describes MLE as used in ZigBee IP, not as it is used in Thread.  "
" the version of MLE described in the draft"

So it seems like this version of the protocol currently applies only to ZigBee IP and ZigBee NAN and no other standards. If so, I'd suggest making that explicit. There's also the question of other versions of MLE. Is there an issue to tell them apart easily? How would one do that?

IANA assignments are per IETF Review. For a protocol whose users are a separate organization, this might be too onerous. I would imagine that Specification Required might be easier for other organizations to further develop the protocol while avoiding collisions and further interop issues (https://tools.ietf.org/html/rfc5226#section-4.1).

Thanks,

Gabriel

_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo