BIND 10 #2657: BIND10 Guide update: DHCPv6 options

[BIND 10 Development]

#2657: BIND10 Guide update: DHCPv6 options
-------------------------------------+-------------------------------------
            Reporter:  tomek         |                        Owner:
                Type:  task          |  stephen
            Priority:  medium        |                       Status:
           Component:                |  reviewing
  documentation                      |                    Milestone:
            Keywords:                |  Sprint-DHCP-20130214
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
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 commit 1e2111996aa44a583fcdf0997a6aa170542f3ea2.
 >
 > I've made a number of edits - correcting typos etc, but also rewriting
 some paragraphs to make them (what I think) is clearer.  I've concentrated
 on the DHCPv4 sections, but some changes may need to be propagated to the
 V6 part of the guide.

 Thanks. I propagated some of your changes to DHCP6 sections as well.

 >
 > In addition, there are several issues:
 >
 > '''Table 17.1'''[[BR]]
 > The "Array" field of the "routers" (code 3) line was empty.  I assumed
 that "routers" is an array, so have filled it in as "true".

 Ok. Thanks.

 >
 > '''Section 17.4'''
 > I've altered the text a bit here.  However, missing in the description
 of the first set of commands is the meaning of the files "array", "record-
 types" and "encapsulate".  Even if you say they should be left blank, they
 should be mentioned.

 Ok. I have added the description of the these fields with an explanation
 why some of them should be left blank.

 >
 > '''Section 17.5'''[[BR]]
 > There seems to be confusion between the name "vendor-encapsulated-
 options" and "vendor-ops" in the third example (Although I've modified the
 text, the name needs to be sorted out.)

 Yep. This is because of the text being copy-pasted from the DHCPv6
 sections. I corrected that.

 >
 > We also need to explain here why we are using this space (i.e. that we
 are talking about sub-options conveyed in a vendor option.)

 I modified the first paragraph in the '''DHCPv4 vendor specific options'''
 and I am hoping it is now clearer.

 >
 > I've put what I think is the explanation for setting a value for option
 43.  This needs to be check.
 >
 >
 >
 > '''17.6 Nested DHCPv4 options (custom option spaces)'''[[BR]]
 > The first paragraph here confuses me - if we need to define a vendor
 space so that we can use a new numbering scheme for options, what did we
 do in the last section (where we used vendor-encapsulated options)?

 I rephrased that paragraph and it should be clearer now. This paragraph
 explains how to create a new option with sub-options within ''dhcp4''
 option space. The other paragraph explained how to configure sub-options
 for the '''existing''' option (where there was no need to create a new
 option space).

 >
 > When we define the DHCPv4 option "container" with code 222, the example
 sets the data type as uint16.  Is this correct?

 It is. It is the example.

 >
 > I've added a paragraph to the end of this section stating that the dummy
 values set for "container" are ignored.  Is this correct?  And will this
 restriction be removed in the future (i.e. should we add a "note"
 element?).
 >
 No. The ''container'' option's type is set to ''uint16''. This means that
 this option conveys uint16 value. In addition, this option encapsulates
 option space called ''isc'' so as all options that belong to the ''isc''
 option space will be included in the ''container'' option. Both things
 imply that the layout of the option and the corresponding values will be
 as follows:
 - option-code (1 byte) = 222
 - option-len (1 byte) = 21
 - uint16 value (2 bytes) = 123
 - subopt1
   - option-code (1 byte) = 1
   - option-len (1 byte) = 4
   - ipv4-address (4 bytes) = 192.0.2.3
 - subopt2
   - option-code (1 byte) = 2
   - option-len (1 byte) = 11
   - string (11 bytes) = "Hello world"

 As you can see, the value being set or the ''container'' option is not a
 !''dummy!'' value because it is used to set the uint16 data field and is
 conveyed to the client.

 If I wanted to define an option which simply conveys sub-options and no
 other data I would set the value of !''type!'' to !''empty!'' in the
 option definition. In such case the !''data!'' parameter would have to be
 left blank when setting the option value.

 >
 >
 >
 >
 >
 >

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