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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Spencer,
>
> Many thanks for your review. See my comments and answer below inline.
>
> Best regards,
>   Jens
>
>
> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]]
> Sent: 14. december 2016 07:57
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Samita Chakrabarti <
> [e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Spencer Dawkins' No Objection on draft-ietf-6lo-dect-ule-08:
> (with COMMENT)
>
> 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"?
> [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,
>
>    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.
>
> [Jens]: Yes, better wording to delete "used".
>
> 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.
>
> [Jens]: The text is made more clear in revision -09.
>
> 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.
>
> [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
>    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].
>
> [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,
>
>    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?
>
> [Jens]: Correct, the wording is changed in new revision -09
>
>  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/
>
> [Jens]: Done in new revision -09
>
> 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?
>
> [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.
>
> 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?
>
> [Jens]: Yes, is done in the new revision -09
>
>
>