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

[Fernando Gont <[e-mail]>]

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