Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)
draft-ietf-6lo-dect-ule-09

3.1.  Protocol Stack

   In order to enable data transmission over DECT ULE, a Permanent
   Virtual Circuit (PVC) has to be configured and opened between FP and
   PP.  This is done by setting up a DECT service call between PP and
   FP.  In DECT protocol domain the PP 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>>

Typo: IWU-ATTRIBUTES

(1) draft-ietf-6lo-privacy-considerations says:

"Specifications should make sure that an IPv6 address can change
     over long periods of time.  For example, the interface identifier
     might change each time a device connects to the network (if
     connections are short), or might change each day (if connections
     can be long).  This is necessary to mitigate correlation over
     time."

This document doesn't seem to provide any guidance about supporting the
ability to change an IPv6 address. At least for non-link-local addresses, I think it would make sense to encourage the use of address generation schemes that align with the recommendation above given expected deployment scenarios.

(2) draft-ietf-6man-default-iids says that the choice of address
generation mechanism should be configurable when a mechanism is specified
to embed a link layer address in an IID. Is there a reason that doesn't
apply here? The document doesn't say anything about it for the link-local
case.

I agree with Alissa's comments. Otherwise, I just have a few nits:

- Abstract: Please expand DECT.

- section 1: The section could benefit from some paragraph breaks.

- 3.2, first paragraph: s/ "implements already fragmentation"/"already implements fragmentation"
-- 4th paragraph:
s/"PP each have"/"each PP has"

I support Alissa's comment on privacy 

The SecDir review didn't get a response as far as I can tell.  Simon had a question and a nit.  I think the draft is okay on those points, but a response for the review would be good.
https://mailarchive.ietf.org/arch/msg/secdir/3E1g-Ccfeq6U0fWcxc5kQ3FL_3w

One tiny comment:
This sounds like a summary of what's specified in TS102.939-1 and therefore should probably not use normative language in this doc:
"In DECT protocol domain the PP 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
   sends a service-change-accept (resume) that MUST contain a valid
   paging descriptor.  The PP MUST be pageable.  Following this,
   transmission of IPv6 packets can start."

I really appreciate the authors taking time to provide this much background for their specification. 

I did finish with some questions and comments, but if I understood the technology better, I'd be balloting Yes.

Could I suggest replacing "an elderly pendant (brooch)" with "a pendant (brooch) for the elderly"? 

Because I was already picturing a very old brooch, I also misread "Generic Access Profile" as "Geriatric Access Profile" further down the page, but there's nothing you can do to fix that ;-)

In this text,

   The used application protocol is negotiated
   between the PP and FP when the PVC communication service is
   established.  

I think you can delete "used", unless "used application protocol" is a term of art for DECT-ULA.

In this text,

   A FP is assumed to be less constrained than a PP.  Hence, in the
   primary scenario FP and PP will act as 6LBR and a 6LN, respectively.
   This document only addresses this primary scenario and all other
   scenarios are out of scope.

Does "all other scenarios" just mean "scenarios where FPs are more constrained than PPs"? If so, that might be clearer.

In this text,

   In
   consequence, the mesh header defined in [RFC4944] for mesh under
   routing are not used in DECT ULE networks.

the term "mesh under routing" doesn't appear in RFC 4944. Did this mean something like "mesh underlay routing"? But if the point is that the mesh header defined in RFC 4944 isn't used, that's probably all you need to say.

In this text,

   Although the
   TPUI is temporary by definition, the same value is usually repeatedly
   assigned to any given PP, hence it seems not suitable for
   construction of IID, see [I-D.ietf-6lo-privacy-considerations].

is this saying 

   Although the
   TPUI is temporary by definition, many implementations assign the
   the same value repeatedly to any given PP, hence it seems not suitable for
   construction of IID, see [I-D.ietf-6lo-privacy-considerations].

?

This may be my own lack of knowlesge at fault, but I'm not sure I understand this text,

   It is expected that the LOWPAN_IPHC packet will fulfil all the
   requirements for header compression without spending unnecessary
   overhead for mesh addressing.

I'm guessing that the point is that you don't have to put the mesh header in, to make header compression perform acceptably. Is that it?

 I think

   The DECT ULE implements already fragmentation and
   reassembly functionality, hence [RFC4944] fragmentation and
   reassembly function MUST NOT be used.

should s/implements already/already implements/

Probably for my own education, but in this text

   Globally uniqueness of IID in link-local addresses are not required
   as they should never be leaked outside the subnet domain.

if those addresses are leaked, does IPv6 Duplicate Address Detection prevent the obvious problems?

Could you add a few words explaining why

   The DECT MAC layer broadcast service is considered inadequate for IP
   multicast.

so the reader isn't left to guess?

section 3, last para: "PP node MUST NOT play the role of a
6LoWPAN Router (6LR)." I reckon that's a bogus MUST NOT.
I think what you mean is that this spec doesn't define how
a PP can be a 6LR. But a bit of h/w and s/w can clearly do
both no matter how many MUST NOTs we write. (That may be a
difference to the usual DECT setup, not sure.)