Hi Alissa, Many thanks for your review. See my comments below.
Best regards, Jens -----Original Message----- From: Alissa Cooper [mailto:[email protected]] Sent: 13. december 2016 20:36 To: The IESG <[email protected]> Cc: [email protected]; Samita Chakrabarti <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Alissa Cooper's No Objection on draft-ietf-6lo-dect-ule-08: (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-6lo-dect-ule-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) draft-ietf-6lo-privacy-considerations says: "Specifications should make sure that an IPv6 address can change over long periods of time. For example, the interface identifier might change each time a device connects to the network (if connections are short), or might change each day (if connections can be long). This is necessary to mitigate correlation over time." This document doesn't seem to provide any guidance about supporting the ability to change an IPv6 address. At least for non-link-local addresses, I think it would make sense to encourage the use of address generation schemes that align with the recommendation above given expected deployment scenarios. [Jens]: A recommendation is added in section 3.2.1 in new version -09 (2) draft-ietf-6man-default-iids says that the choice of address generation mechanism should be configurable when a mechanism is specified to embed a link layer address in an IID. Is there a reason that doesn't apply here? The document doesn't say anything about it for the link-local case. [Jens]: I believe it also applies here, but I don't see the need to mention that specifically in addition to the reference to draft-ietf-6man-default-iids. The link-local addresses are always derived from the link layer addresses. _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
