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 > this construct? 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 training@xxxxxxxx -- 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:
pgpXmOEjWSCSA.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf