Skip to main content

Early Review of draft-ietf-6lo-dect-ule-05
review-ietf-6lo-dect-ule-05-intdir-early-jinmei-2016-12-07-01

Request Review of draft-ietf-6lo-dect-ule
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-10-14
Requested 2016-10-04
Authors Peter B. Mariager , Jens T. Petersen , Zach Shelby , Marco van de Logt , Dominique Barthel
I-D last updated 2016-12-07
Completed reviews Genart Last Call review of -08 by Robert Sparks (diff)
Secdir Last Call review of -08 by Simon Josefsson (diff)
Intdir Early review of -05 by Pascal Thubert (diff)
Intdir Early review of -05 by Tatuya Jinmei (diff)
Assignment Reviewer Tatuya Jinmei
State Completed
Request Early review on draft-ietf-6lo-dect-ule by Internet Area Directorate Assigned
Reviewed revision 05 (document currently at 09)
Result Ready w/issues
Completed 2016-12-07
review-ietf-6lo-dect-ule-05-intdir-early-jinmei-2016-12-07-01
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: 'cjbc@it.uc3m.es' <cjbc@it.uc3m.es>; Carlos Pignataro (cpignata)
<cpignata@cisco.com> Cc: Bernie Volz (volz) <volz@cisco.com>; Terry Manderson
<terry.manderson@icann.org>; Suresh Krishnan <suresh.krishnan@ericsson.com>
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:cjbc@it.uc3m.es]
Sent: vendredi 16 septembre 2016 12:48
To: Carlos Pignataro (cpignata) <cpignata@cisco.com>; Pascal Thubert (pthubert)
<pthubert@cisco.com> Cc: Bernie Volz (volz) <volz@cisco.com>; Terry Manderson
<terry.manderson@icann.org>; Suresh Krishnan <suresh.krishnan@ericsson.com>
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)
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>

_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo