[Int-dir] INT-DIR review of draft-ietf-6lo-dect-ule-06

[神明達哉 <[e-mail]>]

I am an assigned INT directorate reviewer for
<https://tools.ietf.org/html/draft-ietf-6lo-dect-ule-06>.
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.

It is generally well written, and I didn't find any obvious technical
issues that may block publication (but I'm not an expert in this area,
so it's quite possible that I've overlooked something important).

One possibly substantial point I've noticed is that it doesn't talk
about duplicate address detection (DAD).  Whether DAD is assumed to be
performed just as described in RFC4862 or in a 6lo way as described in
RFC6775, or it's considered to be safely skipped, IMO it should be
explicitly described.  And, if it's supposed to be skipped, some
justification text will also be needed.

Some other comments on the draft follow:

- Section 2.3

   [...]  However, it cannot be used to derive
   a globally unique IID.

  I don't understand why this matters.  Although some variants of IPv6
  IIDs may be globally unique, related IPv6 protocols are not supposed
  to rely on such uniqueness anyway.

- Section 3.2.1

   From privacy perspective such constructed link-local address should
   never be used by application layers that could leak it outside the
   subnet domain.

  This sounds a bit awkward.  A link-local address is only valid in
  the associated link, so leaking it outside the link is already a
  broken behavior (for that matter, what specifically "leak" means is
  not very clear to me either).  If there's such an application it
  should be fixed even without thinking about privacy considerations.
  Perhaps this sentence tries to say that this kind of leak is
  extremely bad in terms of privacy while other issues are generally
  just a nuisance.  If that's the intent that makes some sense, but
  the wording will have to be revised.

- Section 3.2.1

   After link-local address configuration, 6LN sends Router Solicitation
   messages as described in [RFC4861] Section 6.3.7.

  Without having much background about 6lo, this sounded awkward on
  first read, since RS can be sent even before configuring a
  link-local address, in which case it's sent with the unspecified
  source address (::).  On reading further I understood it assumed
  (section 5.3 of) RFC6775, but it would be more helpful if this part
  refers to the RFC and/or provides a forward reference to Section
  3.2.2.

--
JINMEI, Tatuya