Re: [libvirt] RFC: adding configuration for standard dhcp options to <network>

5) With so many options, it may save lots of repetitive code in the parser/formatter to make a generic <option> element: <option name='dns-server' value='x.x.x.x'/> <option name='ntp-server' value='y.y.y.y'/> <option name='smtp-server' value='z.z.z.z'/> <option family='ipv6' name='dns-server' value='xxxx::1'/> <option number='201' value='/netboot/boot-dir/' force='yes'/> The final is an example of something I just noticed in the BZ I mentioned above - it is both using an option number and forcing the option to be sent back to the client even if the client doesn't request it. This is apparently needed for some clients. There is a precedent for the "name/value" type of object in nwfilter parameters. The advantages in this case are a) the code for the parser couple possibly be much smaller, with just a single enum + VIR_ENUM_(DECL|IMPL) b) it would be easier to support the options by number (which are all defined somewhere in RFCs, but not all have mnemonic equivalents in dnsmasq) On the other hand, if we allowed any possible option by specifying a number (and even if not, depending on how the parser was implemented), it would be easier to create a situation where "bad stuff" could be injected into the dnsmasq commandline (we should have some type of intelligent parsing of the values - known options should have a type associated with them, and unknown should at least be checked for dangerous characters). Any opinions from those with more XML experience?