> 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
