On 16 okt 2008, at 19:48, Ted Lemon wrote:
The whole notion that we need
to specify a binary format for every new piece of data that may need
to be configured and then wait until both clients and servers are
updated is completely outdated.
Updating an XML schema every time you get a new option is no
different than updating a server configuration or client
configuration to understand a new option. Most existing DHCP
clients and servers are able to be so updated by the user, without
any requirement for a software update, just as would be the case
with XML/HTTP.
Really? Where in my Mac DHCPv6 (oh wait-it doesn't do DHCPv6!) where
in my Vista DHCPv6 config do I add support new DHCP messages?
Generality in parsing binary formats has traditionally been a huge
security hole. Then there is the issue of the MTU that limits the
amount of info that you can put into DHCP without scary workarounds.
Whichever way you slice it, DHCP is a technological coelacanth.
The internet isn't your personal playground where you get to change
stuff just because you don't like it anymore. Changing stuff costs
money, a tiny bit for vendors and huge amounts for operators. It's
not
yours to spend.
That's right. But we are discussing a real problem here, not a
hypothetical problem. We need to solve the real problem. All
these digressions on which protocol is better are fascinating, but
not to the point, unless the solution is to deprecate one protocol
or the other, which I think is unlikely.
So we need to come up with some actual guidance as to what
implementors should do.
Right. But what's the problem exactly?
Didn't we specify what needs to happen in RFC 246x? I see no
compelling reasons to revisit the original intent of the M/O bits, and
sufficient reason to not do so.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
