Subject: [6lo] Changes in draft-ietf-6lo-privacy-considerations-04

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Oct 2016 20:05:40 +0000

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