[6lo] Document Shepherd's comments on draft-ietf-6lo-dect-ule-03

[Samita Chakrabarti <[e-mail]>]

Hello  Peter et.al.,


My apology for the late review which I intended to do much earlier. Please consider the comments and let me know if you have any questions.

General comments:

·         Please add a section on privacy

·         Clarification of several sections are needed

·         Please make the editorial changes suggested below and re-submit the draft

Section 1: Introduction


a)      Please define CAT-iq

b)       DECT ULE needs a pointer to the reference section - please add reference to the specification

c)       s/Many of mechanisms defined for.../A subset of mechanisms defined for/

d)      I-D-ietf-6lo-btle  --> RFC 7668
Section 1.2 : Add more definitions here


Section 2.1, pg 4   says "This document is not considering usage of this DECT ULE MAC broadcast service in current vestion"-is it referring to this -03 version ?  if so, please clarify or reword that this document does not consider broadcast capabilities of DECT ULE.

Figure -1: please add a paragraph explaining each field  in a nutshell. Define DLC

Section 2.2 : please check for page break  so that the figure shows up in one page

Section 2.3 : Suggestion : S/Addressing Model/Link Layer Addressing Model
At the end of pg 5, it says " With such an approach, the FP and PP have to implement ..."  please reword something like "this document specifies a mapping method ..."

Section 2.4 MTU considerations
First paragraph talks about single MAC layer packet 38 octet, and then it says that the DECT ULE MTU is configured for 500 bytes to avoid fragmentation and re-assembly. If 500 bytes MTU size is a default MTU size for this draft/document implementation, then please make it a MUST ( if this document does not support fragmentation/reassembly) else SHOULD. But it breaks the MIN MTU requirement for IPv6 -so fragmentation required at 6lo layer

Section 3 [ last para] discusses the differences between DECT-ULE and behavior and IEEE802.15.4 6lowpan.
                  I think it is better if you address that in a different section under  section 2

Section 3,2 : I am not clear here about the statement that says DECT ULE MUST be configured with equivalent MTU size.  This contradicts section 2.4.  Please clarify. If the minimum MTU size for DECT ULE for this draft is 1280, then please specify that "" MUST be configured with at least 1280 MTU size"
If this is using MTU size 1280, why is header compression is necessary if the data is generally small in size?

Section 3.2.1 : Does DECT-ULE allow  multiple non-link-local addresses ? [ same prefix but different IID?  -- reference section 3.2.4.2 of RFC7668

In this section, there is a text about how to handle privacy " For non-link-local addresses .... Section 3.2.2" :
Editorial suggestion: the text can be specified under a sub-heading of privacy consideration

Section 3.2.2 : Bullet 2:  Why does not it register the link-local address? Do think it is always unique?
NS and ARO must be exchanged irrespective of the method it is using to generate the IID - does the 6LBR needs to know which method is used to generate the IID ? - I guess from 6LBR perspective, it does not care. Why do you have a restriction that 6LN must register only one non-link-local address per available Ipv6 prefix?  If one non-link local address is active at one time in DECT ULE, then please clarify.

Section 3.2.4 : Please clarify the mechanism  or refer to a section in RFC6775 to clearly state what options are used for sending the HC option. Please refer to RFC 7668 similar area for a clear example.

Section 3.2.4.1 :  Refers to "since the node knows that the packet is destined..."   Clarify - what is this "node"'s role.
( 6LBR or destination node?)  How does each node learns about its neighbor's IID ? Please clarify - which one is the neighbor?

Section 3.3 : "what is meant by a 'degenerate scenario' ?

Update reference section appropriately for RFC6778 and add pointer to DECT ULE specification

Thanks a lot!

-Samita