I'm preparing to submit draft-ietf-6lo-privacy-considerations-04 which addresses comments since submission to the IESG. I believe the changes are simple editorial ones that do not affect WG consensus, but are enumerated below.
The AD assigned two INT reviewers, both of which found no blocking issues but mentioned some nits. The first INT reviewer, Jouni Korhonen, sent two nits: > 1) Page 4 first paragraph states it takes a year to scan 26 bit of id space. > Even if the math is given in the next paragraph it is not clear what are the > assumptions to number of devices per link. I take it is one device on that > link. I made no change, but responded via email explaining that it's simply a statement of time to completely scan a number of addresses, independent of any such assumptions. To scan 2^26 addresses at 2/second, it takes 2^26 = 67108864 addresses at 2 addresses per second = 33554432 seconds = 388.36 days or "about a year" So no such assumption about the number of devices per link is relevant here, it's just simple math. > 2) Page 5 table has "6 or ???" for NFC.. it would be good to either replace > "???" with > something meaningful or explain why "???". An earlier version of the NFC draft was unclear as to whether there was an alternative. In the current NFC draft there is no alternative but now it's only 5 bits, since section 3.3 of the latest NFC draft says: NFC-enabled devices are identified by 6-bit LLC address. In other words, Any address SHALL be usable as both an SSAP and a DSAP address. According to NFCForum-TS-LLCP_1.1 [3<https://tools.ietf.org/html/draft-ietf-6lo-nfc-04#ref-3>], address values between 0 and 31 (00h - 1Fh) SHALL be reserved for well-known service access points for Service Discovery Protocol (SDP). Address values between 32 and 63 (20h - 3Fh) inclusively, SHALL be assigned by the local LLC as the result of an upper layer service request. So only values 32-63 are relevant for normal addresses and I have now changed "6 or ???" to "5", since it seems 0-31 are like anycast addresses similar to RFC 2526 if I understand correctly. The other INT reviewer was JINMEI Tatyua who said: > One possible point that my warrant a discussion is that this document doesn't > seem to be very specific to > resource constrained nodes (as the title and abstract suggests). I don't see > anything tightly specific to such > nodes except for some parts of Section 3. Even in Section 3 most of the > discussions seem generic. I wonder > whether such general privacy issues regarding IPv6 addresses are already > covered by some existing documents. > If so, this document could be much shorter by just referring to such > documents and focusing on a few points > specific to 6lo nodes. If not, we might rather consider publishing it as > such a generic document. Since it's already a 6lo consensus document and it's not covered elsewhere, we don't want to change the technical content in any significant way, but it is true that some parts are more generic. I proposed we reword the title and abstract slightly without making any other changes, and the WG chair (Gabriel) agreed and asked me to post this to the list. Title OLD: Privacy Considerations for IPv6 over Networks of Resource-Constrained Nodes NEW: Privacy Considerations for IPv6 Adaptation Layer Mechanisms Abstract: OLD: This document discusses how a number of privacy threats apply to technologies designed for IPv6 over networks of resource-constrained nodes, and provides advice to protocol designers on how to address such threats in adaptation layer specifications for IPv6 over such links. NEW: This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link layer protocols, and provides advice to protocol designers on how to address such threats in adaptation layer specifications for IPv6 over such links. Finally, the WG Chair (Gabriel) also had two nits: Section 1: > RFC 6973 [RFC6973] discusses privacy considerations for Internet > protocols, and Section 5.2 in particular covers a number of privacy- > specific threats. Section 5.2 could potentially be confusing as to whether it meant section 5.2 in RFC 6973 (which it does) or section 5.2 in this document (which has no such section). NEW: RFC 6973 [RFC6973] discusses privacy considerations for Internet protocols, and Section 5.2 of that document covers a number of privacy- specific threats. Section 3.2: OLD: statisical NEW: statistical Fixed. Dave
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
