> -----Original Message-----
> From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Michael Richardson
> Sent: Friday, September 23, 2016 9:57 AM
> To: samita Chakrabarti <samitac.i...@gmail.com>
> Cc: 'lo' <6lo@ietf.org>
> Subject: Re: [6lo] privacy enhanced L3 addresses derived from short L2
> addresses
> samita Chakrabarti <samitac.i...@gmail.com> wrote:
>     > Right, there is no document on 6lo address formation  that standardizes
>     > the
>     > following suggestion made in the privacy document.
>     > It is though covered in the charter as part of the extension of 6lowpan
>     > stack.
>     > I don't quite relate the connection with 6lo-paging-dispatch...
> If we were to define a way to map short-L2 addresses, using the PANID and
> L2-key, into random-looking 64-bit IIDs, then we'd want to be able to indicate
> in 6lo compression mechanisms that we want to compress addresses out.
> I realize upon further thought that 6lo-paging-dispatch is not the right place
> to define what is really a small extension to RFC6282.  But I didn't think 
> that
> roll-routing-dispatch was either.
> I'm not sure what to do here:  it seems that 6lo-privacy-considerations ought
> to make a stronger statement about what to do, and to the point of having a
> normative reference to something concrete that ought to be done.

The audience of 6lo-privacy-considerations is document authors (not 
You want a document that's for implementers to be compliant to.  One doesn't
already exist (but one would indeed make sense).  In my view, it's not worth
holding up the privacy-considerations spec, but just pursue it in parallel 
there is interest/energy.


6lo mailing list

Reply via email to