BIND 10 #2233: Option Definition Design - V6 Options

[BIND 10 Development]

#2233: Option Definition Design - V6 Options
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  marcin
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:         |  DHCP-20121004
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  dhcpconf                           |           Sub-Project:  DHCP
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => marcin


Comment:

 Reviewed version 15 of [http://bind10.isc.org/wiki/DhcpOptionDefinition].
 I've made some small changes to correct typos etc. and saved version 16.

 In the following review, text quoted comes from version 15 of the
 document:

 '''Introduction'''[[BR]]
 > the program will create OptionXDefinition objects only for those
 standard options which are not already defined in user options space
 Presumably this means that standard options will be defined in the source
 code?

 >  a UserXOption object is created to represent it
 Would not one of the existing OptionX objects be better?

 '''Options Definition (outline design)''']
 > Array indication - if this value is set to true than multiple
 occurrences of the record are allowed
 Could this be a simple integer? 0 implies unlimited, positive is the
 number of occurrences expected, negative is any number up to the modulus
 of the given value.

 > Suboptions - holds the list of suboptions being encapsulated by this
 option. This list is obtained by querying the list of all options
 belonging to the custom defined space specified in the Configuration
 Manager.
 This seems to belong in the vector of structures part of the definition.
 Perhaps if the data type in the option indicates "suboptions", another
 element in the structure should be a list of option definitions that
 describe them?

 > The name is qualified with the vendor name (if present).
 OptionXDefinition objects are held in one of two areas, one for system-
 wide options and the other for vendor options. Within the system-wide
 area, a map object allows the option to be located by name and another map
 by value.
 Do you mean "another map by code"?


 > In the vendor options area, the names are unique as each option is
 qualified by a vendor name, hence a map can be used. To identify options
 by value, a multimap is needed as options from different vendors may have
 the same code.
 So if the options have the same vendor (or enterprise) number and same
 code, how are they distinguished on an incoming message? Also, what about
 user-defined options?

 > When an option has been identified in a received packet, the option code
 and name is used to identify appropriate option factory function
 AFAIK, the incoming message does not include the option name, only the
 code.

 > If the option format does not match any common format
 Does this mean "if the type of the data in the option definition is
 'record'"?

 > Access to the data is through another data structure in UserXOption
 Are these different from the current OptionX objects?

 >Internally, parsed data is held as string for each data element.
 I think a vector<uint8_t> would be more appropriate, as the data may be of
 arbitrary type.

 > If the server has to add user-defined options to its responses, it is
 assumed that elsewhere in the configuration will be the values of the
 parameters to be used.
 Check with Tomek.  I assume that if any options (system-defined or user-
 defined) are to be added to the response, their will either (a) be
 specified in the configuration file or (b) be generated by the server "on
 the fly".  If the former, the values should have already been compared
 against the definitions and OptionX objects created holding the value.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2233#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development