On Thu, Aug 17, 2006 at 11:35:21AM -0700, Damien Neil wrote:
> On Aug 17, 2006, at 10:02 AM, David W. Hankins wrote:
> >There's a simpler solution: Section 6.3 should be removed.
>
> I don't think 6.3 is all that complicated, but I suspect that you're
I suppose it depends on the implementation. ISC DHCP's failover was
implemented when section 6.3 was a "MAY" (I don't actually know the
history, it might go further back), and the developer at the time
chose a simple loop that digested the option space, to cut out their
values and place them in known locations for later scrutiny by whatever
processing function was to come after (wether it be a BNDUPD or a
BNDACK or etc). A table is looked up for each option to determine
where and how to cut the option contents out.
In short, our code currently doesn't know it's a binding update until
after the option space has already been shunted into indexed fields,
by which time it's a little late to separate the message into multiple
transactions.
In such an architecture, the changes to support this feature are not
plain or simple. Short of a complete rewrite, the feature would be
impossible to support in a production capacity (too much spaghetti
code).
I wouldn't mind rewriting it, mind you, but the motivation would not
be to make it act substantively differently than it does today.
For others, admittedly, it might not be that hard to support, but it
is still markedly 'more complex' than simply having all options
be treated the same...a concise format that leaves little if anything
open to interpretation. Tell me, how might one interpret this:
Non-IP Address/Non-client specific options first
assigned-IP-address option for the first IP address
Options pertaining to first address, including at least the
binding-status option and others as required.
assigned-IP-address option for the second IP address
Options pertaining to second address, including at least the
binding-status option and others as required.
...
Trailing options (message digest).
Which option(s) are non-client-specific? Open to interpretation. If
an option listed in that field appeared later in another ip-address-
delimited section, we can interpret that it should probably take
precedence over the first one (but this is still interpretation). So,
should the new value then also be applied to all subsequent ip-address-
delimited fields (eg you over-write the earlier value and use that to
the end of the packet)? Probably not, but it's still interpretation
(and an implementation might very well do that for efficiency). Is a
message-digest option implicitly an end-of-field marker? What do you
do with other options that appear there, and how do you know they
don't apply to the previous transaction? If a server processes each
binding update as it goes (rather than batching the transactions until
after this message is "parsed"), and commits the changes before, let
us imagine, an invalid option or corrupted format entry is discovered,
how should it respond? Transmit a binding ack for the transactions it
has so far? But the specification says you have to have all of them.
Rollback (or maybe not!) and pretend the packet was lost, then reset
the connection (or whatever you choose to do to deal with protocol
format errors)? Again, more interpretation.
So even so, I still don't think it's worth it to complicate the
protocol in this way for at best a trivially small decrease in bytes
transferred on the wire...for a protocol that isn't even bandwidth
conscious, let alone starved!
It is better that all the message option fields be indistiguishably
processed from all other message types option fields - so that code
may be reused, and simplified.
Keep it simple, stupid.
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpeG1axTzg6L.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg