> -----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 implementers). 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 assuming there is interest/energy. Dave _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
