[dhcwg] extending the DHCPv4 option space, VSO usage -- was: Re: issues with draft-grochla-80211-dhcp-option-00

[Alfred Hönes <[e-mail]>]

Ted,
in response to my comments you wrote:

> On Sep 22, 2010, at 5:45 AM, Alfred Hönes wrote:
>> Given the scarcity of DHCPv4 option numbers and the intimate
>>    relationship to IEEE 802.11, wouldn't it be a much cleaner
>>    solution to use vendor-specific options for this purpose (under
>>    an IEEE owned vendor ID) than further reducing the DHCPv4 option
>>    code name space -- the latter should preferably be reserved for
>>    options with a more general applicability?
>
> No, that's not what vendor options are for.  ...

Glen Zorn seems to be in support of my opinion.
Other voices?

>                                    ...  We actually have a fairly
> substantial set of option codes available still, although it's
> definitely limited.  What I've been planning to propose, but haven't
> done yet, is to reserve a bunch of options that can be used for
> extended option codes.  ...

+1

RFC 3942 scratches at some arguments why extension schemes might
be perceived as penalizing from the PoV of prospective applicants.

The most important, general point is supported by IAB documents on
protocol and protocol extension design:  An extension mechanism
MUST be well-specified, testable, implemented and deployed at large
scale to make it generally usable.  This means in particular that:

o  The mechanism needs to be thoroughly specified sufficiently
   long enough before actual need to make use of it arises,
   so that support for the mechanism can be expected to be
   already deployed when it's needed.
   Corollary: An encouragement to go ahead with this task ASAP !

o  Carrying information is only one part of the game in DHCP;
   requesting specific information from the DHCP server is equally
   important.  Therefore, a uniform, standardized method to request
   specific options from the extended option code space is needed.
   Most likely, an Extended Parameter Request List option will be
   needed for this purpose.

o  To ensure the above goals, the mechanism needs built-in mandatory
   testability.  I.e., code points reserved for testing need to be
   an integral part of such specification and support for these
   code points needs to be mandated for implementations.
   This would allow advance screening of deployments to determine
   the suitability of instantiating extended options.

BTW: According to my observations, one of the con's frequently heard
  against the Vendor-specific Information Option (#125) defined in
  RFC 3925 (and its less versatile predecessor in RFC 2132) is that
  -- although a recommendation is given for structuring such options
  in sub-options --, no uniform, standardized mechanism is available
  to request delivery of specific sub-options of particular #125's.
  Therefore, it might be worth considering to specify a new
  Extended Parameter Request List option that equally serves the need
  for standard options from the extended option code space _and_ the
  needs for vendor specific options.


>          ...  I'm thinking to reserve sixteen of the remaining codes
> that are available.  ...

Well, currently #126 and #127 are set aside for such purpose.  If you
want more than two (e.g. 16), a rfc3942bis effort would be needed!
(And, btw, is the time ripe for a rfc3679++ effort as well,
 to get rid of more cruft ?)

>            ...  These would then be used to introduce a second byte
> of option code.  16x256=4096 option codes.  ...

Currently, based on RFC 3942, 2x256=512 extended option codes would
become available.

OTOH, with a proper sub-option request mechanism at hands (see above),
arguably the simple registration of a handful of IETF/DHCWG assigned
"vendor codes" would allow usage of the #125 mechanism, giving an
open-ended number of n*256 sub-options (for n IETF vendor codes);
this would allow "growth on demand".

One possible method to implement option requesting (yet without
addressing the aforementioned similar goal for sub-options of
vendor-specific information options) would be to use sub-option 0
of each 'base' option code (currently #126 and #127) for extended
option code requesting within the same 'family' of extended options;
that would lead to a very simple syntax of that (partial) request list.

>                             ...  Combined with a form of fusion,
> the machines had ...  oh wait, wrong movie.  Anyway, I really
> don't think we should allow the potential for option code space
> depletion to drive us to use vendor options.

Aren't these dedicated to specific environments bound to a particular
vendor or SDO ?

Given a good infrastructure and proper guidelines,
vendor specific options seem to have the additional benefits of more
rapid specification and implementation cycles, and reducing the work
load on the DHCWG and the IESG.

Kind regards,
  Alfred.