Subject: [6lo] AD evaluation: draft-ietf-6lo-dect-ule-05

From: Suresh Krishnan <[email-masked]>
Date: Wed, 10 Aug 2016 02:40:43 +0000

Hi authors,
    I have done my AD evaluation on this draft. I do have a few comments I 
would like you to address before I send the document further through the process.

* Section 1

Please swap these two sentences so that DECT gets defined before use

Move:
     DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
     technology building on the key fundamentals of traditional DECT /
     CAT-iq but with specific changes to significantly reduce the power
     consumption at the expense of data throughput.

after:

     DECT (Digital Enhanced Cordless Telecommunications) is a standard
     series...

* Section 1.2

It is unclear what this section is intending to do. The way it is done now, 
it looks like it is trying to redefine what 6LBR and 6LN are. This needs to 
be fixed. Suggest something like the following

6LBR: 6LoWPAN Border Router as defined in [RFC6775]. The DECT Fixed Part
        plays this role in DECT-ULE networks.
6LN:  6LoWPAN node having a role as defined in [RFC6775]. The DECT
        Portable part plays this role in DECT-ULE networks.

* Section 2.1

s/technics/techniques/

* Section 2.2

OLD:
     This document does only address this primary scenario.

NEW:
     This document only addresses this primary scenario and all other 
scenarios are out of scope.

* Section 2.3

The scope of RFPI uniqueness is not clear from the following text.

Each DECT FP is assigned a RFPI during manufacturing.  This identity has the 
size of 40 bits and is globally unique for a FP.

Does this mean that the RFPI is globally unique? If so, delete the text "for 
a FP". If not please explain what you mean.

Similar question for the IPEI as well.

* Section 2.4

The minimum MTU required to be supported for IPv6 is 1280. Does the following 
text imply that the default IPv6 MTU in DECT ULE will be 1280.

" In order to support complete IP packets, the DLC layer of DECT ULE SHALL
    per this specification be configured with a MTU size that fits the
    requirements from IPv6 data packets"

If so, I would like the document to explicitly state that. If not, why not?

* Section 3.1

This mandatory text is unclear. Are you specifying this as mandatory for IPv6 
implementation or is it something that needs to be done before even starting 
on the IPv6 part? Please clarify?

"The PP SHALL specify the <<IWU-ATTRIBUTES>>..."

* Section 3.2.1

The modified EUI-64 derivation seems to be wrong (Either the method is wrong 
or the end result is wrong). This needs to get fixed. Let's take the RFPI 
11.22.33.44.55 case.

The way I see the derivation is as follows

RFPI (11.22.33.44.55) -> MAC-48 (80:11:22:33:44:55)

MAC-48 (80:11:22:33:44:55) -> IID (82:11:22:ff:fe:33:44:55)

(as the U/L bit needs to be flipped to make the modified EUI-64)

Please clarify what you intend to happen. The same error exists for the IPEI 
based modified EUI-64s as well

Also a reference to the draft-ietf-6lo-privacy-considerations-02 might be in 
order here as well as some guidance to the amount of entropy needed in the 
typical connection scenarios.

* Section 3.2.2

What is the reasoning behind this restriction?

"The 6LN MUST register only one IPv6 address per available IPv6 prefix"

Can you please explain how a node can change its address when this 
restriction exists?

* Section 3.2.4.1

How are IPv6 multicast addresses recreated with the specified parameters for 
RFC6282 (i.e. M==0)

* Section 3.3

Why is this text included when PP acting as 6LBR has been disallowed by text 
in Section 2.2?

"Other scenarios can be imagined where a PP is acting as 6LBR and providing 
Internet connectivity for the FP."

Thanks
Suresh