Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work?

["Bernie Volz (volz)" <[e-mail]>]

These are questions / issues for the WG to reach consensus on. So let's see what others have to say & if people actually have use cases where they would want to make use of this (or close to it) algorithm.

I would recommend you publish a pending update if you have it.

- Bernie (from iPad)

> On Apr 3, 2015, at 6:33 PM, Fernando Gont <[e-mail]> wrote:
> 
> Hi, Bernie,
> 
> I'm kind of surprised about the question :-), since my mental model of
> this I-D as that it should be WGLC'ed rather than  abandoned.
> 
> Regarding your thoughts, please find my comments in-line...
> 
>> On 04/01/2015 07:30 PM, Bernie Volz (volz) wrote:
>> 
>> To the WG and co-authors of this document, as a follow up from the
>> Dallas (IETF-92) DHC WG meeting, there is the question as to next
>> step(s) for draft-ietf-dhc-stable-privacy-addresses.
>> 
>> In thinking about this some, my feeling is:
>> 
>> -          Drop the work. There is little reason for defining this for
>> DHCPv6 servers as there are no “interoperability” issues.
> 
> If you look at the RFC series, there are plenty of documents that
> specify policies that do not necessarily result in interoperability
> issues: e.g., RFC4086, RFC1948, RFC6056. RFC7217.
> 
> In many cases, there are underlying requirements to prevent
> interoperability issues. And some of the possible choices have other
> implications (e.g., security-related). Hence having guidance or
> providing good implementation approaches is more than valuable.
> 
> 
> 
>> o   If there are multiple servers operating on a link and they aren’t
>> coordinating activities in some way (i.e. perhaps DHCPv6 failover or
>> some common database), they will likely not be able to lease from the
>> same pool of addresses anyway.
> 
> Actually, an approach such as that pecified by this document is
> mentioned in RFC7031 itself. e.g.:
> 
> "  Also, the typical large address space (close to 2^64 addresses on /64
>   prefixes expected to be available on most networks) may make managing
>   address assignment significantly different from DHCPv4 failover.  In
>   DHCPv4, it was not possible to use a hash or calculated technique to
>   divide the significantly more limited address space, and therefore,
>   much of the protocol that deals with pool balancing and rebalancing
>   might not be necessary and can be done mathematically."
> 
> So this is indeed and algorithmic approach for coordinating the databases.
> 
> 
> 
>> o   Sure, if you change the server to a different server implementation,
>> it may have different a algorithm, but does this really matter (and it
>> is fairly rare in the first place)?
> 
> If stability is an issue, yes.
> 
> 
> 
>> o   And, there are also issues with the “range of addresses” model if
>> the range is expanded or reduced, since this causes a change to the
>> “stable” addresses.
> 
> This was already fixed (in the version that I didn't post because of the
> I-D cutoff). We even discussed how to solve this issue on-list.
> 
> 
> 
> 
>> o   So, do we really need this?
>> 
>> -          If people do feel that the work should continue (and
>> eventually advance), the document should not be a “Standards Track” but
>> “Informational”.
> 
> Wasn't this an implicit question in the wg call for adoption?
> 
> 
> 
>> So, I will propose that the DHC WG “drop this work” (mark the ID as
>> dead). Objections? Comments?
> 
> Me, I object to that. :-). My comments and rationale can be found above.
> 
> Thanks!
> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>