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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Jinmei,

Thanks a lot for the review!

Carlos

On Thu, 2016-10-06 at 18:14 -0700, 神明達哉 wrote:
> 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
> 
> _______________________________________________
> Int-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-dir