RE: 3484bis and privacy addresses

[Dave Thaler <[e-mail]>]

> Forgive me if I read your reply wrongly, but you seem to point the blame for
> there being an incomplete solution for remote management squarely at
> draft-ietf-6man-addr-select-opt-03.

No, I'm saying the issues you're raising are issues with draft-ietf-6man-addr-select-opt
not rfc3484bis.

> So what would I like to see happen?
> ===========================
> 
> What about defining a conceptual "address selection policy table" in
> RFC3484bis in addition to the "prefix policy table"?
> 
> It would contain a complete list of the conceptual knobs and switches that
> influence the behaviour of RFC3484bis end nodes, conceptual variable
> names, conceptual variable type, what behaviour the variable sets (cross
> referenced to the section), default settings (where these are already agreed in
> the WG) etc.

Currently it does have a complete list in text.   For system-wide switches
that control sorting, there's only one.

> Then draft-ietf-6man-addr-select-opt-03 would simply define how to
> transport those options over DHCPv6, rather than having to define the
> options themselves.

Agree that draft-ietf-6man-addr-select-opt should define how to transport
over DHCPv6 system-wide administrative options controlling sorting.
Currently we only have 1 and draft-ietf-6man-addr-select-opt is missing it.

> Equally, if an implementor wanted to set these options via a config file, or AD
> group policy, or any other management process, they'd have a check list of
> things to do as well.
>
> And if there are ever future extensions to RFC3484bis (e.g. a new rule to
> introduce dollar cost of network links or QoS factors into the address
> selection process), any new switches or new default behaviour could also be
> added to this conceptual "address selection policy table".
> If we'd already done this in RFC3484 it would have probably avoided a lot of
> pain with divergent implementations.
> 
> To be clear: I don't necessarily see the need to define new knobs or switches
> right now: just to clarify what existing knobs or switches will conceptually be
> called, what their conceptual types are (e.g. boolean), how/when they're set,
> what behaviour they influence, and their default behaviour (if agreed), plus a
> hint of how to add new knobs and switches in the future. This conceptual
> approach has been used very successfully in ND (RFC4861) and other
> standards, and I think it would address my current concerns of there being
> too much hard coding in address selection.

I take your comment as asking for a summary table in rfc 3484bis of
system-wide config options.   That could be done as a purely editorial
change, although if there's only 1 thing in the table it's less interesting.
But if others in the WG think this would be helpful, then yes we can do that.

-Dave