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

From: Jens Toftgaard Petersen <[email-masked]>
Date: Mon, 3 Oct 2016 14:44:25 +0000

Hi Suresh,

Thank you very much for your review. I have just submitted a revised version that addresses all your comments.

See additional comments below in colour inline.

Best regards,

  Jens

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]]
Sent: 10. august 2016 04:41
To: [email-masked]; [email-masked]
Subject: AD evaluation: draft-ietf-6lo-dect-ule-05

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

Done

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

Definition changed per your proposal

* Section 2.1

s/technics/techniques/

Done

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

Agreed and done

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

Wording has been change to reflect that the RFPI is globally unique in the DECT address space, but not in IEEE address space

* 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?

Wording is changed to make it that 1280 octets is supported

* 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>>..."

Wording changed

* 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

Wording changed. Note that intermediate is not MAC-48. Result is OK

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?

After some analysis we have decided to remove this restriction.

* Section 3.2.4.1

How are IPv6 multicast addresses recreated with the specified parameters for

RFC6282 (i.e. M==0)

Wording changed

* 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."

Removed, ok

Thanks

Suresh