Hi Tomek -
Thanks for these edits. My points are all addressed, though I wish to
push a little more on changing the focus of the following in the document:
On 2/15/16 2:45 PM, Tomek Mrugalski wrote:
<snip/>
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.
Then I suggest this variation:
"In deployed systems, address allocation strategies such as choosing the
next
sequentially available address are chosen over strategies such as
pseudo-random
allocation across the available address pool because the latter are more
difficult
to implement efficiently."
To be very clear (and I do _not_ want to put this discussion in the
document), an implementation could keep a structure (probably a
linked-list) of blocks of unallocated addresses, and very efficiently
select an address pseudo-randomly from the addresses in that structure,
modifying the structure to make the next selection just as efficient
(similarly modifying the structure when addresses are returned to the pool).
This would not have the performance degradation that the simple strategy
you currently discuss has.
While they're entertaining, I think discussing _either_ way of
approaching such a random selection algorithm distracts the reader from
the point of understanding the privacy implications.
<snip/>
RjS