Re: [mif] Route option for DHCPv6 - next steps?

["Tony Hain" <[e-mail]>]

Ted Lemon wrote:
> On Apr 3, 2012, at 12:24 PM, Tony Hain <[e-mail]> wrote:
> It appears you missed my point that my personal preference is to avoid
using
> DHCPv6 for this single function, because I have no other ongoing need. At
> the same time, as I said my personal preference doesn't matter, and I will
> defend the right of others to have the tools they expect.
> 
> This argument would be a good justification for perpetuating the use of
NetBIOS.
> 
> What I mean is that if we are trying to replicate functionality, that
doesn't motivate 
> us to choose DHCP over RA, or vice versa: we can just replicate the
functionality in 
> whatever way is most architecturally appropriate, and be happy that we
have provided 
> people with the tools they need to do their job.

If enough people wanted the IETF to work on standardizing issues related to
NetBIOS, it would be wrong to ignore that.

> If, on the other hand, what we need to do is to produce functionality that
>  matches someone's mental model of how networks work, then that's a very
different 
> problem.   But we do not want to do that; if we did, we would have adopted
NetBIOS.

It is not the IETF's place to tell people what protocols to run. The role
here is to tell implementers to be consistent so the operators have a chance
of doing something that works.

> Nobody's saying that people can't use NetBIOS if they want, and nobody's
saying 
> people can't use IPv4 behind a NAT if they want.   But your argument
doesn't really 
> address the question, which is, is there a *need* for the DHCPv6 route
option?  
> Is there a use case that RA doesn't address, or addresses poorly, but that
DHCPv6 route
> does address.

And you keep refusing to hear the use case that "an RA option does not work
for people that want to manage related functionality in their existing DHCP
server". Requiring some things in an RA and others in DHCP is just broken;
both operationally and architecturally. 

> Tony, when I asked you to specifically say why RA didn't address your use
case, 
> you didn't answer my question.   Instead you said, effectively "no, people
want NetBIOS."  
> That's orthogonal to the question.   *Is* there something RA can't do well
that 
>DHCPv6+Route can?   If so, can you clearly state what that is?   If not,
then you haven't 
>articulated a use case.   "Somebody wants to use a hammer" is not a use
case.

See above about the brokenness of requiring both RA and DHCP to make a
network work ...

Let's try a different analogy ... We need to deliver Champaign to clients.
The RA approach is the equivalent of a custom developed stemmed and fluted
crystal glass, while DHCPv6 is equivalent to a generic ceramic coffee mug.
We are NOT discussing delivering different types of Champaign, it is coming
from the same bottle. The only discussion point is the delivery mechanism.
My point is both need to exist and be viable because they serve different
operational models and efficiency needs.

Your argument against allowing the DHCP option to exist amounts to an
irrational fear that somehow allowing people to choose to consume from their
existing generic ceramic mug will be detrimental to your ability to consume
from the crystal glass. While I do understand some degree of that fear being
derived from the insanity of the ongoing IESG stance that the IETF's role is
to restrict everything to one-size-fits-all, then force everyone to adopt
that even when it doesn't work efficiently for them; that still doesn't
justify fighting against someone else's approach. If MIF is doing its job
right, it will present both the RA and the DHCP drafts at the same time and
tell the IESG to get over itself. What we have though is the ongoing
infighting between DHCP and RA that has done nothing but hamper progress for
15 years. If we don't define both in parallel, there is a very real chance
that the IESG will kill off efforts to define the second one, further
bolstering the claims that the IETF ignores the operations community. That
said, if we know they are going to kill one off anyway we should give them
the RA one; because any vendor can define an option in DHCP then bypass the
IESG stupidity by going straight to the RFC editor with an Informational
draft that explains to the community how to interpret that option number.

If we get 15 years down the road and one of the operational models has so
significantly dominated the other that the lesser one becomes operationally
irrelevant (re: your NetBIOS comments), then the right thing to do is define
the lesser one as Historic and move on. Again, the IETF is not here to tell
people how to run their networks, it is here to make sure the products they
attempt to use will work consistently with each other. The operator gets to
choose which approach is most efficient for their local needs. 

Tony