Subject: [6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-dect-ule-08: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 13 Dec 2016 22:56:31 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-6lo-dect-ule-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Jens Toftgaard Petersen <[email-masked]>
Date: Thu, 15 Dec 2016 22:07:08 +0000

Hi Spencer,

Many thanks for your review. See my comments and answer below inline.

Best regards,
  Jens

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: 14. december 2016 07:57
To: The IESG <[email-masked]>
Cc: [email-masked]; Samita Chakrabarti <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Spencer Dawkins' No Objection on draft-ietf-6lo-dect-ule-08: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

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"? 
[Jens]: Ok, I will change that.

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,

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

[Jens]: Yes, better wording to delete "used".

In this text,

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

[Jens]: The text is made more clear in revision -09.

In this text,

   In

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.

[Jens]: You are right there is no definition of "mesh under routing". Your suggestion will be implemented in the new revision -09

In this text,

   Although the

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].

[Jens]: Ok, for better wording in new revision -09

?

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

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?

[Jens]: Correct, the wording is changed in new revision -09

 I think

[Jens]: Done in new revision -09

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

[Jens]:  What we had in mind was to mention that link-local addresses should never be exposed outside the local domain, for example by application protocols or other means. Obviously Duplicate Address Detection will not detect any such situation.

[Jens]: Yes, is done in the new revision -09

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 21 Dec 2016 14:55:42 -0600

Hi, Jens,

Thanks for the quick response - I'll be fine with what you do in -09.

Spencer

On Thu, Dec 15, 2016 at 4:07 PM, Jens Toftgaard Petersen <[email-masked]> wrote:

> Cc: [email-masked]; Samita Chakrabarti <
> [email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> 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,
>
> header defined in RFC 4944 isn't used, that's probably all you need to say.
>
> [Jens]: You are right there is no definition of "mesh under routing". Your
> suggestion will be implemented in the new revision -09
>
> In this text,
>
>    Although the
> [Jens]:  What we had in mind was to mention that link-local addresses
> should never be exposed outside the local domain, for example by
> application protocols or other means. Obviously Duplicate Address Detection
> will not detect any such situation.
>