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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
