Re: [dhcwg] I-D Action: draft-ietf-dhc-problem-statement-of-mredhcpv6-08.txt

[Alan DeKok <[e-mail]>]

  I have some minor feedback.

  The link to the "ISC kea hook developers guide" is to a page which says "access denied".  Perhaps this link is better:

https://reports.kea.isc.org/dev_guide/df/d46/hooksdgDevelopersGuide.html

  Section 1 says in part:

   Some people would suggest that administrators modify the open-source
   DHCPv6 server to solve their problems.  However, it takes
   considerable time to understand the code of an open-source DHCPv6
   server, not to mention the time-consuming task of debugging errors,

  This comment isn't true of all Open Source DHCP servers.  Some can be extended only via source code changes.  Others such as FreeRADIUS support a policy language.  The policy language permits basic if / then / else functions, and option creation, validation, modification, and deletion.

  Similar text to this is in Section 3.2 and in Section 5.2.  It should clarify that there are many ways of writing policies for DHCP servers, not all of which require source code changes.

  Section 4.2.2 has good discussion of options.  But it stops at a problem statement, without addressing implementations (as is done in the other sections).  For example, Kea supports custom options:

https://kea.readthedocs.io/en/kea-1.6.2/arm/dhcp4-srv.html#dhcp4-option-spaces

  FreeRADIUS has similar support.  The benefit of this approach is that the software can be updated to support new options via a configuration file.  And it does not require any source code changes. 

  This practice means that a particular release of a DHCP server implementation can have a lifetime much longer than would otherwise be possible.

  Alan DeKok.