BIND 10 #2233: Option Definition Design - V6 Options
BIND 10 Development
do-not-reply at isc.org
Thu Oct 11 13:11:02 UTC 2012
#2233: Option Definition Design - V6 Options
-------------------------------------+-------------------------------------
Reporter: | Owner: stephen
stephen | Status: reviewing
Type: task | Milestone: Sprint-
Priority: | DHCP-20121018
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 marcin):
* owner: marcin => stephen
Comment:
Replying to [comment:5 stephen]:
> Reviewed version 15 of
[http://bind10.isc.org/wiki/DhcpOptionDefinition]. I've made some small
changes to correct typos etc. and saved version 16.
I created version 18 of this document. I introduced several changes to the
text that should address most of the bullets from the review.
----
>
> 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?
Yes. 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?
I renamed UserXOption to CustomOption because UserXOption suggests that it
is reserved for user-defined options but user-defined options can be also
represented by other classes, e.g. Option6AddrLst.
The CustomOption will be derived from the Option class and will extend it
with data structures suitable to hold "array or records" and similar.
However Options of this type will be created only in case there is no
better candidate for this. Such "better candidates" have accessors and
mutators that access and modify particular data fields within the option
and perform validation on input buffer.
>
> '''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.
I wouldn't complicate things that much. We already have the 'record'
option type that allows to enumarate the exact data fields we want to see
in the option. So, if I wanted to put the limitation on the number of
fields (say 3) I would simply create the option definition with type set
to 'record' and add 3 fields of certain type to it. Array is a kind of
"open" option where I can add unlimited number of fields of the certain
type (e.g. multiple IPV6 addresses). The implication here is that I can't
add suboptions here because the definition has no way to determine where
the suboptions start in the buffer.
>
> > 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?
I resigned from "vector of structures" and replaced it with the vector of
"data types". This is because the planned OptionDefinition functionality
will not operate on particular fields but it will rather try to match
their types with the common patters and return factory functions. For this
reason information like "field name" is not needed here.
AFAIK, sub-options may encapsulated by whole option and mixing option data
fields with suboptions is not what we want to have. In other words, I
don't want options like:
- option_code
- option_len
- data_field_1
- data_field_2
- suboption_1
- data_field_3
- suboption_2
For this reason I didn't want to put this into the data structure that is
simply aimed to keep the information which data fields are stored in this
option and in which order. Suboptions are meant to be appended at the end
of option.
>
> > 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"?
Yes.
>
>
> > 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.
I added some more comprehensive description in the document about handling
sub-options.
>
> > 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'"?
No. Records can be matched with the common option formats too. For
example, I can define the record that comprises one element of "uint8"
type. This is still a record but the option constructed from this
definition will contain single field of uint8 type. I do have Option6Int
class already so I can use it for this option.
By ''common format'' I rather understand the format that has a C++ class
derived from Option class it fits. However I can also think of some
present classes which may fit the layout of custom option but should not
be used for user-defined options. For example: IA_NA comprises 4 fields of
the type uint_32 and has the corresponding class Option6IA. I user defines
the 'record' with 3 uint32_t types he should not get Option6IA just
because it has the same data layout. In the code we will need to filter
out such specialized classes and never return them for user-defined
options.
>
> > Access to the data is through another data structure in UserXOption
> Are these different from the current OptionX objects?
Yes, I am planning to derive another class so as we can access particular
data fields in the unified way.
>
> >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.
That's true. I changed this in the text.
>
> > 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.
>
Yes. Options can be configured "statically" from the configuration file or
generate "on the fly". The latter case is tricky because if you override
the format of the option which is generated "on the fly" you don't know if
your data matches the format. It can be verified by checking the
definition and it they don't match you don't know how to set the data for
it. You can either:
- force a user that this option must be statically configured
- rely on some conditional expressions that we may or may not want to
implement
- prohibit overriding standard options that are prepared "on the fly"
--
Ticket URL: <http://bind10.isc.org/ticket/2233#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list