BIND 10 #1228: V4 packet library - option processing

[BIND 10 Development]

#1228: V4 packet library - option processing
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  tomek
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:  major  |  DHCP-20111109
                  Component:  dhcp   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DHCP
Feature Depending on Ticket:         |  Estimated Difficulty:  0
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by tomek):

 Replying to [comment:6 stephen]:
 > Reviewed commit bfab5a33ceabe3f0d31bd465d13308c8b84adf68
 >
 > '''src/lib/dhcp/libdhcp.h'''[[BR]]
 > unpackOptions4 needs its own header.
 Why? This is part of the library. Traditionally, you provide a single
 header that exposes all methods offered by a library. User is not expected
 to use all methods, just the ones that are suitable for specific use.

 > Should unpackOptions4() be taking an !InputBuffer object?
 No. Due to several reasons. Honestly, DHCPv4 packet format is a mess.
 There is options field that contain options. We want to parse that.
 However, if certain option is specified (I don't recall exact name of that
 option), also SNAME and/or FILE fields should be parsed as options as
 well. There are some options (like option 82) that contains sub-options.
 In such case, we could use unpackOptions() in implementation of that
 specific option classes to parse only a range of buffer, not the whole
 buffer. So this will need to parse only fragments of InputBuffer, never
 the whole buffer. There may be cases, when we get content for such option
 from somewhere else (e.g. custom option specified by user). In that case
 we don't really have input buffer at all.

 > packOptions - should this be called packOptions4?
 In theory - yes, in practice - no. Once v6 code is refactored to use
 Input/OutputBuffer, there will be only packOptions() and unpackOptions().
 Unpack will have extra parameter that designates universe (v4 or v6).
 Consider current name (packOptions()) as a first step of having those
 names unified.

 Review will continue on Monday...

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