On 02.02.2016 17:38, Robert Sparks wrote: > Document: draft-ietf-dhc-dhcpv6-privacy-03 Reviewer: Robert Sparks > Review Date: 2Feb2015 IETF LC End Date:4Feb2015 IESG Telechat date: > Not yet scheduled > > Summary: Ready with nits that should be addressed before publication Thanks for your thorough review. I did my best to address your comments. The soon to be published -04 is available here: https://github.com/dhcwg/privacy/blob/master/draft-ietf-dhc-dhcpv6-privacy-04.txt You can see the diff here: https://github.com/dhcwg/privacy/commit/11d08e981fc503d11f31938af05316b7e881bfd6 (scroll down to draft-ietf-dhc-dhcpv6-privacy.xml to see the actual changes). > The reference to ietf-6man-ivp6-address-generation-privacy should be > normative, and when this document is pointing to it because it is > discussing a field carrying a generated address, it should be more > explicit about why it's making the reference. It is normative now. Every reference to this I-D mentions specific section (See Section 3.2 of ...) and explains that the reference was made to point to an extended description of each type of attacks. If this is not sufficient, can you point to specific section or text that requires further improvement? > In section 4.3 the paragraph on Hash allocation should note that even > a well implemented hash does not mitigate the threat of correlation > over time. Added. Also added an explanation about the performance. See my response below why I think it's appropriate. > In section 4.3, the paragraph on Random allocation comments on the > poor performance of a specific simplistic implementation of random > selection. More efficient algorithms exist. But the discussion is > mostly irrelevant to the document. Please simplify this paragraph to > focus on the benefits of random allocation. I somewhat disagree. First, there are more efficient algorithms known, but they are not always used. This document is a analysis, so we tried to provide an analysis of what's actually happening in actual implementations. In an ideal world where privacy is the top priority every implementation would use truly random allocation using hardware entropy generators. Sadly, the reality of DHCP servers market is that performance matters a lot. Lowered performance is a price for better privacy. This fact directly affects DHCP server implementors, which are the target audience for this document. These are my arguments why the discussion about performance penalty is there and should stay in my opinion. But I think I see your point. The performance aspect was raised only in random allocation, so it may be mis-interpreted as a way to discredit random strategy. It is not. I added similar discussion to hash allocation and added a bit of clarification text. Hopefully it is not biased in any direction. BTW This strategy is called random, but the text now explains that it's really pseudo-random. I can envision a way to hook a hardware random number generator to a device running DHCP server, but I never heard about such a solution. Therefore I think pseudo-random is the right word to use here. Please let me know if the updated text is satisfactory for you. If not, I'd love to know which part requires further work. > Should section 5.3 also call out mapping IP addresses into > geolocation? Added a paragraph. I'm not a geolocation expert by any stretch of imagination, so please correct me if I got it wrong. In general, any global address assigned by DHCP (or SLAAC for that matter) is susceptible to the geolocation procedures and the text now clearly mentions that. > Why doesn't section 5.5 also talk about things like MAC addresses? Because there are no MAC addresses in DHCPv6, at least not in the general case. This is a common surprise, so I added a clarification text that tries explains it, without going into too much details (it's a broad topic). Please let me know if the text is sufficient or you want me work on it further. > Section 5.6 could probably borrow words from RFC7258 - it should at > least reference it (currently there is only a reference from the > introduction.) Good point. It now borrows heavily and references RFC7258. Also updated one out of date reference. Thanks a lot for your review and comments. Tomek