BIND 10 #2232: Option Definition Design - V4 Options

BIND 10 Development do-not-reply at isc.org
Fri Sep 14 09:16:18 UTC 2012


#2232: Option Definition Design - V4 Options
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  stephen                            |                Status:  new
                       Type:  task   |             Milestone:  Sprint-
                   Priority:         |  DHCP-20120917
  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      |
-------------------------------------+-------------------------------------
Description changed by stephen:

Old description:

> This task involves the design of the option definition system for IPv4.
> In particular:
>
> * Where V4 are specified (probably the configuration database, but the
> design should verify that).
> * How the user specifies the V4 options: how the option is specified, how
> data types are specified, how the system handles sub-options.
> * How the information is held in the server and used to parse and write
> options.
> * How "standard" options (i.e. the standard ones specified by RFCs) are
> included in the system. (Should then be in the database, or hard-coded?
> If the latter, how can they be easily extended as new options are
> created.)

New description:

 This task involves the design of the option definition system for IPv4.
 In particular:

 * Where V4 options are specified (probably the configuration database, but
 the design should verify that).
 * How the user specifies the V4 options: how the option is specified, how
 data types are specified, how the system handles sub-options.
 * How the information is held in the server and used to parse and write
 options.
 * How "standard" options (i.e. the ones specified by RFCs) are included in
 the system. (Should they be in the database, or hard-coded?  If the
 latter, how can they be easily extended as new options are created.)
 * Will the user be able to override "standard" options.

--

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


More information about the bind10-tickets mailing list