[Int-dir] FW: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Bernie and all:

Please note that I posted the attached review per the int area assignment.

Take care,

Pascal

-----Original Message-----
From: Pascal Thubert (pthubert) 
Sent: mardi 27 septembre 2016 11:17
To: '[e-mail]' <[e-mail]>; Carlos Pignataro (cpignata) <[e-mail]>
Cc: Bernie Volz (volz) <[e-mail]>; Terry Manderson <[e-mail]>; Suresh Krishnan <[e-mail]>
Subject: RE: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05

I posted my review to the 6lo list and the draft authors, Carlos.

Please find it attached for your convenience; 

Take care;

Pascal

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[e-mail]] 
Sent: vendredi 16 septembre 2016 12:48
To: Carlos Pignataro (cpignata) <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>
Cc: Bernie Volz (volz) <[e-mail]>; Terry Manderson <[e-mail]>; Suresh Krishnan <[e-mail]>
Subject: Int Area Directorate Review Assignment - draft-ietf-6lo-dect-ule-05

Hi Carlos and Pascal:

You are next up on the Int Area Directorate review assignment queue and the Int ADs have requested a review of draft-ietf-6lo-dect-ule-05 (see https://tools.ietf.org/html/draft-ietf-6lo-dect-ule-05). Please note the request below, but again, you are only being asked to review ONE of these documents.

Please response to this email as soon as possible (and within 72 hours) to indicate whether you CAN or CANNOT review this document. Please assume that the review needs to be completed within 2 weeks (by September 30th).

For more details, see https://www.ietf.org/iesg/directorate/intarea.htm
l.

Thanks much in advance!

- Carlos (& Bernie)

--- Begin Message ---

Dear all :



I am an assigned INT directorate reviewer for draft-ietf-6lo-dect-ule-05. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.



Document: draft-ietf-6lo-dect-ule

Transmission of IPv6 Packets over DECT Ultra Low Energy

Reviewer: Pascal Thubert

Review Date: Sept 27, 2016

IETF Last Call Date: TBD



Summary: Issues concerning the subnet model that needs to be explicited.



Major issues:



- Reference to draft-ietf-6lo-privacy-considerations and privacy of addresses should be addressed (related to lifespan of IEEE EUI48 addresses, random but permanent is still not too good)

- Subnet model (Section 3.3) should be described in more details, indicating NBMA Multi-Link SubNet (MLSN). Suggestion to review/emulate RFC 7668 (section 3.2.1 and last paragraph of 3.2.2)

- Reference to draft-ietf-6lo-backbone-router could be made to address the L3 perspective of node mobility

- Some IMPERATIVE is extraneous. (RFC2119: "Imperatives of the type defined in this memo must be used with care and sparingly.  In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm")



Minor issues:



- inline on the right of the original text, with a "<<" prefix



---











6Lo Working Group                                            P. Mariager

Internet-Draft                                          J. Petersen, Ed.

Intended status: Standards Track                                 RTX A/S

Expires: November 17, 2016                                     Z. Shelby

                                                                     ARM

                                                          M. Van de Logt

                                             Gigaset Communications GmbH

                                                              D. Barthel

                                                             Orange Labs

                                                            May 16, 2016





        Transmission of IPv6 Packets over DECT Ultra Low Energy





< snip>





1.  Introduction



   DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface       <<< spell DECT on first use

   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.  DECT (Digital          <<<  DECT spelling

   Enhanced Cordless Telecommunications) is a standard series

   [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced

   Technology - internet and quality) is a set of product certication

   and interoperability profiles [CAT-iq] defined by DECT Forum.  DECT





< snip>





   In its generic network topology, DECT is defined as a cellular

   network technology.  However, the most common configuration is a star

   network with a single FP defining the network with a number of PP

   attached.  The MAC layer supports both traditional DECT as this is          << "both" is unclear, can you rephrase?

   used for services like discovery, pairing, security features etc.

   All these features have been reused from DECT.







< snip>









       [DECT ULE PP]-----\                 /-----[DECT ULE PP]

                          \               /

       [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]

                          /               \

       [DECT ULE PP]-----/                 \-----[DECT ULE PP]





       Figure 2: DECT ULE star topology                                   << suggestion to place a forward reference to section 3.3  on how IP uses that (MLSN)







   A significant difference between IEEE 802.15.4 and DECT ULE is that

   the former supports both star and mesh topology (and requires a

   routing protocol), whereas DECT ULE in it's primary configuration

   does not support the formation of multihop networks at the link

   layer.  In consequence, the mesh header defined in [RFC4944] for mesh





< snip>





   When bound to a FP, a PP is assigned a 20 bit TPUI which is unique       << in reference to draft-ietf-6lo-privacy-considerations it would be good to indicate whether this is short lived or long lived, so as to figure if an IPv6 address can be derived or not.

   within the FP.  This TPUI is used for addressing (layer 2) in

   messages between FP and PP.





< snip>





   Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)

   MAC-48 address additionally to the DECT identities to be used by the     << same as above, it would be good to indicate whether this is short lived or long lived, so as to figure if an IPv6 address can be derived or not.

   6LoWPAN.  During the address registration of non-link-local addresses

   as specified by this document, the FP and PP can use such MAC-48 to

   construct the IID.





< snip>





   support complete IP packets, the DLC layer of DECT ULE SHALL per this    << there is a MUST later in the document, no need to uppercase here; whether this setting is needed is debatable

   specification be configured with a MTU size that fits the

   requirements from IPv6 data packets, hence [RFC4944] fragmentation/

   reassembly is not required.                                              << unclear. .. since DLC supports fragmentation there is no need for 6LoWPAN fragmentation is there? The adaptation described here only provides value if the DLC fragmentation is armful. Is that the case ?



   It is expected that the LOWPAN_IPHC packet will fulfil all the

   requirements for header compression without spending unnecessary

   overhead for mesh addressing.



   It is important to realize that the usage of larger packets will be

   at the expense of battery life, as a large packet inside the DECT ULE

   stack will be fragmented into several or many MAC layer packets, each

   consuming power to transmit / receive.                                  << proof? fragments increase reliability and reduce the size of retried pieces. is there a paper showing pros vs cons or is this the author intuition ?



2.5.  Additional Considerations



   The DECT ULE standard allows PP to be registered (bind) to multiple

   FP and roaming between these FP.  This draft does not consider the      << Why ?? this is where the backbone router becomes handy. If the subnet model is clarified to NBMA / MLSN then it is possible to assign the same prefix to multiple 6LBRs and connect them through a 6lo backbone router

   scenarios of PP roaming between multiple FP.  The use of repeater

   functionality is also not considered in this draft.



< snip>





3.1.  Protocol Stack



   In order to enable transmission of IPv6 packets over DECT ULE, a

   Permanent Virtual Circuit (PVC) has to be opened between FP and PP.

   This MUST be done by setting up a service call from PP to FP.  The PP   << is this MUST coming from this spec or from DECT? if the latter then just say "this is done by..."

   SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other)

   message before sending a service-change (resume) message as defined

   in [TS102.939-1].  The <<IWU-ATTRIBTES>> SHALL define the ULE

   Application Protocol Identifier to 0x06 and the MTU size to 1280

   octets or larger.  The FP MUST send a service-change-accept (resume)

   containing a valid paging descriptor.  The PP MUST be pageable.





< snip>





3.2.  Link Model



   The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is

   layer 2.  The DECT ULE implements already fragmentation and

   reassembly functionality, hence [RFC4944] fragmentation and             << this is repeating and sight contradictory. suggestions to keep the text starting at RFC4944, dropping the beginning of the sentence

   reassembly function MUST NOT be used.  The DECT ULE DLC link (PVC)

   MUST be configured with a minimum MTU size of at least 1280 octets in   << Not sure this is needed

   order to meet the size requirements of IPv6.







< snip>







   compression context if any, and from address registration information

   (see Section 3.2.2).



   Due to DECT ULE star topology, each branch of the star is considered

   to be an individual link and thus the PPs cannot directly hear one      << indicate that this is NBMA, multilink subnet. See related text in 6LoWPAN BTLE RFC 7668

   another and cannot talk to one another with link-local addresses.

   However, the FP acts as a 6LBR for communication between the PPs.

   After the FP and PPs have connected at the DECT ULE level, the link

   can be considered up and IPv6 address configuration and transmission

   can begin.  The FP ensures address collisions do not occur.



3.2.1.  Stateless Address Autoconfiguration



   At network interface initialization, both 6LN and 6LBR SHALL generate

   and assign to the DECT ULE network interface IPv6 link-local

   addresses [RFC4862] based on the DECT device addresses (see

   Section 2.3) that were used for establishing the underlying DECT ULE

   connection.



   The DECT device addresses IPEI and RFPI MUST be used to derive the      << SHOULD vs. MUST: with a MUST, this means that the 6LoWPAN code does never expect a link local that is not fully elided (3.2.4.1.)?

   IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR,

   respectively.







< snip>







   see [RFC7136].  For example from RFPI=11.22.33.44.55 the derived IID

   is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived

   IID is 00:01:23:ff:fe:45:67:89.                                        << This seems to be setting permanent addresses (admittedly Link local), and the privacy properties of such addresses should be addressed, eg addresses do not (lust not) leak in app layer in any fashion



   As defined in [RFC4291], the IPv6 link-local address is formed by

   appending the IID, to the prefix FE80::/64, as shown in Figure 4.









< snip>





   (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses

   (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque     << This seems to be setting permanent addresses; discussion on renewing addresses would be good, ref to draft-ietf-6lo-privacy-considerations would help, and the security section could just point here as opposed to use IMPERATIVE

   addresses [RFC7217] SHOULD be used by default.  In situations where







< snip>







   2.  A DECT ULE 6LN MUST NOT register its link-local address.  A DECT  << the registration has 2 roles, DAD (which can be avoided for globally unique addresses) and SLLA mapping. This seems to indicate that SLLA is deduced from the LL so there's special code to avoid using an ND cache?

   ULE 6LN MUST register its non-link-local addresses with the 6LBR by





< snip>





   accordingly.  The NS with the ARO option MUST be sent irrespective of

   the method used to generate the IID.  The 6LN MUST register only one  << why can't a device form more than one address?

   IPv6 address per available IPv6 prefix.





< snip>



   the DAM field of the compressed IPv6 header as CID=1, DAC=1 and

   DAM=01 or DAM=11.  Note that when a context is defined for the IPv6   << considering the rest of the optimizations, why don't you have a /128 context for the 6LBR?

   destination address, the 6LBR can infer the elided destination prefix

   by using the context.







< snip>







3.3.  Subnets and Internet Connectivity Scenarios       << Missing scenario below, same /64, with backbone router









                         6LN                 6LN

                          \                 /

                           \               /

                    6LN --- 6LBR ------ 6LBR --- 6LN

                           /               \

                          /                 \

                         6LN                 6LN



                    <DECT ULE> <Backbone> <DECT ULE>









< snip>

--- End Message ---