I am flattered that my simple opinion required not one but two such
voluminous responses. Thank both of you for the compliment.
I don't think repeating my (unchanged) opinion is useful or will have
any real impact on the Internet, so I had not planned on responding.
But there is something in Dave Crocker's reply that I need to clear
up, as I gather it is my fault:
On Wed, Sep 27, 2006 at 10:32:58AM -0700, Dave Crocker wrote:
David W. Hankins wrote:
Quite the opposite. DHCP server software commonly refers to shared
code to process DHCP option contents.
So citing this section of RFC3315 is telling an implementor to
reuse that code.
Oh. So there is a specification for existing DHCP mechanism(s) that use
If I gave you the impression that the ISC DHCP server and client
software shared common code or libraries with, say, the Kame server
and, say, the Apple OSX client (if there is one), that is incorrect.
I was referring to practices internal to implementations, reuse of
code internal to each.
And so long as I'm transmitting, there is one other thing;
| returns. And what you, as a server implementer, already know
| or can take advantage of is of absolutely no use to them.
One might infer from this that I am creditable for ISC's DHCPv6
Server implementation, and that isn't correct.
Let me be clear: the only person who deserves that credit is Shane
Kerr. If I deserve any credit, it is for helping him find bugs.
We are both, however, equally culpable for any blame.
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP. Email
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
Description: PGP signature
Ietf mailing list