Dave Thaler <[email protected]> wrote: > 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.
Only if there were an obvious document to put this new work into in a timely way, would I continue to suggest holding it up. I see that there isn't, so let's get this one out. After some thought, the ability to compress l3 IIDs because they match match L2 addresses only works on the first (for source) and last (for dest) hop, and not at all in the middle, or near root for traffic not going to the root. Being able to derive/decompress a 64-bit L3 IID in a deterministic, but private to holders of the L2 key, from a shorter set of bits that would go into IPHC header is a better goal. I think that this fits into charter for 6lo. (It would be a good codestand.ietf.org project too!) -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
