[kea-dev] Thoughts on reading the ARM documents

[Shawn Routhier]

While reading through the ARM document I
cleaned up some minor typos (trac ticket 3620)
and had some questions and comments.

For those of you on this list that don't know me I'm the lead
engineer on the current ISC DHCP code.  When I talk about
what the current code does this should not be viewed as
a requirement or even a strong suggestion that Kea should
follow along.  I'm trying to describe what the current code
does and what users may be using - we may decide that Kea
should do the same thing, or have a similar feature but done
in a different way or that it isn't necessary for Kea for some reason.

There were three sections in the original document but I've
removed one section - that one was for changes I had made to
the ARM document that seemed like issues but for which I wasn't
completely sure.  They are on the trac ticket.

For the other two the first is for the general thoughts I had while 
reading the docs.  This covers things that the current code does 
that Kea may want to do, areas where Kea may distinguish itself from
the current code, ideas for futures etc.

The second is for more changes to the docs and some questions about 
the code that may require changes to the docs.  In some cases this is 
simply a step farther than 2 - there seems to be something a bit iffy and 
I think I understand it, but I'm not sure enough to make changes.
In other cases we may want to add more text to either be more clear or to be different than
ISC DHCP.  And there are some that may be feature requests in disguise.

I imagine that after some discussion a number of these may turn into tickets
for future work.  The priority will need to be evaluated over time.

I currently plan to do some more work on the ARM document and so as I understand
things better or get somebody to explain some of the items in the second section
to me I can open another ticket and do more work on the document.

I haven't tried to polish the text of these so some of the descriptions
may need some re-working but they should be sufficient to start the discussion.

************

General thoughts about the documentation and the code
1) Many users use something like nagios to watch over their dhcp servers
it would be useful to either work well with those tools or provide our own
that does similar nannying.

2) Can there be more than one configuration file for the keactrl?  It appears as if there
can be only one for both v4 and v6 - if I want two files (say two diffeernt groups run the
v4 and v6 stuff) can I do so?

3) I have some concerns about the reload option.  In general what people have been asking
for in ISC DHCP is the ability to change a running system (via OMAPI mostly).  I think those
that have asked for a reload capability want to change the config but not go through the full
startup sequence.  If Kea is quicker to start (quite likely as it doesn't have the same
issues in building the database) this may not be an issue.  But the example is that an
admin wants to add a new pool to a server without having to stop and restart the server.

In the current code we have the options to test the lease and config files, is the
reload command part of the replacment for that feature?  If not will we get such a feature
in the future?

4) Is there a background option for starting a server directly?

5) Note for failover support - the state of the lease will need to be stored in the
lease database. (Free, backup and active at least, possibly others for transition states).


6) 6.2.3 Inteface selection - can the wildcard be used as part of a string such as
"eth*" or "eth1.*"?  can the interface code deal with "funny" intefaces (vlans, bonded,
fractionals etc).  Doing a better job than the current code would be a selling point
so if it does so making that clear is probably worthwhile.

7) Table 6.3 - is there an option for a FQDN that will be looked up via DNS and then
the ip address sent out in the option?

8) 6.2.8 - for the vendor encapsulated space, can we pick and choose which one to send based
on something in the request?

9) 6.3 - note that we don't implement server id checks in the ISC DHCP server by default.
I don't know if this is an issue for many clients.

9) 7.1 (and maybe for v4 as well) do we plan to allow a default config file at some time?
We do so now for ISC DHCP, I'm not sure if people like that.  I think the distros kind of like
having very little on the command line.  But maybe they will mostly use the keactrl?

10) In ISC DHCP we currently do different things for hosts vs pools.  In v4 we don't check
to see if an address is in both and can hand it out twice if the configuration is incorrect.
In v6 we claim to check and won't hand out addresses from a pool that are also static.
(Just an FYI for when static entries are handled)

11) 7.2.7 in the current code we can have issues with prefix lengths.  If we can allocate
a /56 but somebody asks for a /60 we won't give them anything.

12) I'm looking at the option-defs - can we format something that is a value followed
by an array of items?  

13) Are we using the same "vendor-encapsulated-options-space" for both v4 and v6?  Or
maybe it is "vendor-opts-space" in v6 as the text says in 7.2.10?

14) In using client classification if a client has a class but the config doesn't include
a subnet for that class but does include an unclassified subnet will the client get an
address from the unclassified subnet?  Or if it has a class does there have to be a matching
subnet?

15) 8.2.1 - is there a default value for the dns_server_timeout?  The example shows 100
(milliseconds) which seems a bit low but I haven't checked to see if the specs provide any guidance.
For comparison 4.1 allows for 1 second while 4.2 & 4.3 are up to the Bind9 code but I
believe are in the multiple second range.

16) 8.2.2 - We may wish to provide or ask the Bind9 folks to provide a mechanism to
produce the proper tsig_key structure such that an admin can cut and paste from the
output into the config file.

17) 8.2.4.x - We allow the admin to set the suffix for the reverse zone name for v4
and have a request to do the same for v6.

****************

Items that I have questions about but didn't change.
1) I note that the copyright years in share/kea/dhcpdb_create.* are 2013
should these be updated to 2014?  (In Bind they update all of the copyrights
every year in ISC DHCP we only do so when we touch a file.  If Kea wants to
do it every year (I think it should) we should probably have a script to do so).

2) 3.4.4 - mentions "prepare the Python scripts", we don't use python anymore do we?

3) 3.4.5 - when would ldconfig be required

4) 6.2 and 7.2 the description of the lease database in the v4 and v6 sections doesn't match the example.
The example has multiple paramaters (type, persist and name) while the description claims
only one paramater.  Or perhaps there is a missing example block right next to the lease
database description?

5) 6.2.4 it sounds as if auto-generated ids always start from 1 and increase.  They won't
start from the id of a defined subnet?  And if they overlap what happens?  I have 5 subents
1-4 and number five specifies
 "id": 2,
Does the answer change if the first one is specified as 2?

6) 6.2.6 when using hex strings which formats do we allow "xx yy", "xx:yy" "xxyy".  It would
probably be good to allow all of them if possible (eventually).

7) I see we use both option-data and option-def - it might be useful to mention that explicitly
people glancing through the examples may miss that difference.

8) 6.2.12.2, the text says we will alwayss do a remove and add in case 2 and remove in case 3
are those also gated by the FQDN flag bits?  Do we attempt a removal if we haven't attempted
an addition?

9) 6.2.12.2 - The text says that N=1, S=1 packets will be dropped.  Will they be completely
dropped (no address allocated) or will the DDNS step be dropped?

10) 6.2.12 - generated names, it appears as if the leading hyphen always required
is that true?  or if one sets the generated prefix to "" will it be left out?

11) 6.2.14 - is echo-client-id a global or can it be more specific?

12) 6.4.1 - can there be only one relay and ip address?  or can there be multiple of either?

13) in 7.2.6 we mention there is no danger when using gigantic address pools.  
I assume the danger would be to allocating large amounts of memory which would
seem to be true for pre-allocation.  But as we aren't doing clean up yet don't we
have a potential for usng large amounts of resources over time?  should we mention
that?

14) 7.2.8 the comment mentions numbers in the first column, but I don't see any?

15) In general there seems to be some confusion over ". " or ".  " to end a sentence,
that is should a period at the end of a sentence be followed by 1 or 2 spaces.
I typically do the second and I think there were some uses of that before my edits
but I also see a lot of the first.  We should probably pick one and be consistent.

16) 7.2.16.1 - we may wish to make clear if the server-ip can be v4 or v6 for both dhcp4
and dhcp6.  In this text we describe the loop back as a v4 address (127.0.0.1) and the
example as a v6 address.

17) 7.2 - we should probably allow for two options in the name creation area.  I can
see people wanting either what is there or a fully spelled out address (no zero compression
on v6 addresses) to make sure the names are all the same length for other processing.

18) D2 - we currently don't support finding the appropriate DNS server via queries.
We may want to make this explicit and to indicate our plans in this area.  I believe
that some customers may want this feature.

19) 8.2 - the v4 and v6 configuration sections start by showing the appropriate block
within the entire config file (mostly this means and extra pair of braces outside of
the block).  I'm wondering if D2 should do the same.

20) 8.2.3.1.1 - What happens if i include a hostname paramenter?  What is the planned
response in the future if an entry has both a hostname and ip_address?  (I'm curious
about what will happen if I try and prepare for when hostname is available.)

21) 9.1 - perhaps expand a bit on the use of raw sockets?  Mostly that they are necessary
for (more or less) directly connected clients and not so much for relays that use IP?