Subject: [dhcwg] issues with draft-grochla-80211-dhcp-option-00

From: Alfred Hönes <[email-masked]>
Date: Wed, 22 Sep 2010 14:45:29 +0200 (MESZ)

I have two fundamental concerns and found several minor issues with
draft-grochla-80211-dhc-option-00 :

a)  The scope of the proposed options is _very_ restricted.
    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?

    Such specification would perhaps need support from IEEE 802.11,
    but could be published as an Informational RFC.

b)  The option formats for DHCPv6 and DHCPv4 differ in a substantial
    way.  Firstly, the option codes are drawn from independent
    namespaces of different bit size (single-octet vs. 16-bit option
    code fields) and the option-length fields have both different
    width and different semantics.  Further, the processing rules
    are different in a subtle way (e.g. concatenation in DHCPv4).

    Therefore, options for DHCPv4 and DHCPv6 need to be specified
    independently, and for the independent option code name spaces
    independent IANA assignment requests need to be included.
    Further, the ways to request delivery of options is different
    in v6 from v4 and needs to be spelled out differently.
    The syntax of the information elements should be specified,
    in order to allow proper treatment in mechanisms to configure
    DHCP servers intended to serve this option (the current draft
    only describes the option-code and option-length fields for the
    DHCPv6 case).

Minor issues:  Please ...
-  perform an in-depth grammar check of the text (with a particular
   focus on the use of articles and on singular/plural mismatches);
-  avoid such silly phrases as "DHCP protocol" -- where the "P" already
   stands for "protocol".
-  Where you say "[to] relay on", I suspect you mean "[to] rely upon".
-  Finally, I suggest to use the current I-D boilerplate text for
   the front page "Status of this Memo" -- including the placement
   of the Abstract in front of that boilerplate text.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Sep 2010 08:08:54 -0700

>    options with a more general applicability?

No, that's not what vendor options are for.   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.   I'm thinking to reserve sixteen of the remaining codes that are available.   These would then be used to introduce a second byte of option code.   16x256=4096 option codes.   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.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 23 Sep 2010 09:21:16 +0700

Ted Lemon [mailto://[email-masked]] writes:

> No, that's not what vendor options are for.   We actually have a fairly
> substantial set of option codes available still, although it's
> definitely limited.   

Good answer to the first point, but I think that the second is still valid:
the option specified does seem to be a good candidate for VSO &
documentation via an Informational RFC to me.

...

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 23 Sep 2010 09:57:05 +0200 (MESZ)

Ted,
in response to my comments you wrote:

> On Sep 22, 2010, at 5:45 AM, Alfred Hönes wrote:
> 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
> 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.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Sep 2010 10:05:16 -0700

> documentation via an Informational RFC to me.

How is the IEEE a vendor?   I really don't see the problem here--whether this is informational or not, it's a perfectly cromulent application for a DHCP option, and it doesn't make sense for it to be a vendor option.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Sep 2010 10:11:43 -0700

I'm not going to respond point-by-point to your helpful and insightful comments because it would get rather long, but suffice it to say that you've raised some very useful issues that I will take into account when I write up the option extension document.

Your point about the extended parameter request list, however, pretty much puts to rest the idea that this should be a vendor option.   If it's a vendor option, the client can't request it.   So it really can't be a vendor option.

You've proposed a solution to that problem--standardize the format of vendor options, and add a vendor option request option.   I think it's unnecessary, but don't really oppose it.   But that solution would require a bunch of standards work, and I suspect it would be controversial.   It's not fair to delay this draft on the basis of the potential that that solution might someday be standardized.   And I still think that this sort of option isn't what vendor options are for--my understanding of vendor options is that they're for vendors--e.g., Cisco, not IEEE.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 23 Sep 2010 21:01:05 -0400

In my opinion, almost all "Vendor Specific" options in various
protocols are misnamed. Maybe "organizational" would be better. Of
course, vendors can use them, but lots of entities other than product
vendors have OUIs or the like. To take a hypothetical example, lets
say the an IETF WG specifies a cipher suite usable in 802.11. Cipher
suites in 802.11 can be specified by an OUI plus one byte. Just
because the IETF isn't a vendor of products, there is no reason it
shouldn't use the IETF OUI to create a code point to specify this
hypothetical cipher suite in 802.11 frames. In fact, this is used as
an example in RFC 5342.

Thanks,
Donald

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 24 Sep 2010 08:11:39 +0700

...
> ...I still think that this sort of option isn't what vendor options are
for--
> my understanding of vendor options is that they're for vendors--e.g.,
> Cisco, not IEEE.

Maybe.  However, that makes the DHCP usage of the vendor-specific construct
considerably more limited than other IETF protocols (e.g. RADIUS & Diameter
(in which even the IETF is considered a "vendor", assigned the vendor-id of
0)).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Sep 2010 21:43:49 -0700

On Sep 23, 2010, at 6:01 PM, Donald Eastlake wrote:
> Just

True enough, but here it's not just a matter of choosing an OUI.   DHCP vendor-specific options have quite different semantics than regular DHCP options.

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 24 Sep 2010 15:33:20 +0200 (MESZ)

At Fri, 24 Sep 2010 08:11:39 +0700, Glen Zorn wrote:
>> ...I still think that this sort of option isn't what vendor options
>> are for-- my understanding of vendor options is that they're for
>> vendors--e.g., Cisco, not IEEE.
>
> Maybe.  However, that makes the DHCP usage of the vendor-specific
> construct considerably more limited than other IETF protocols (e.g.
> RADIUS & Diameter (in which even the IETF is considered a "vendor",
> assigned the vendor-id of 0)).

That's also my understanding.  My expectation/desire is to have
similar treatment of this question in affected IETF protocols.
Please note that, in turn, the IEEE has assigned an OUI to the IETF
(e.g. for use in 802 SNAP headers).  So why shouldn't "we" behave
reciprocally for the IETF/IANA managed comparable namespace?
[ And I agree with Donald that the IEEE term is much better,
  "organization" should be the keyword, not "vendor". ]

Looking at the so-called "Vendor ID" registry, which actually is the
IANA registry of "Enterprise IDs", you'll find there the names of
a lot of organizations that are not vendors/producers of some kind
of equipment but service providers of different kind, universities,
research institutes, federal administration branches, counties,
cities, publishers, banks, assurance companies, etc.

Regarding Ted's previous comments on the difficulty in establishing
a uniform [sub-]option request format for vendor options, it should
be recalled that both the original (#63) and the enhanced (#125)
DHCPv4 vendor information option specifications strongly recommend
a uniform format for sub-options.  This could be used as a base
for follow-up work, restricting the scope to that format, and thus
avoiding complications and discussions.

Kind regards,
  Alfred Hönes.

--

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Sep 2010 08:45:13 -0700

> avoiding complications and discussions.

I'm sorry, this just seems like noise to me.   Who cares what some other IETF protocol does?   This isn't some other IETF protocol--this is a specific protocol, with specific semantics.  The proposal to use vendor-specific options for this option ignores the fact that you can't *request* one of these options.

There seems to be a strong sudden groundswell of support for using vendor options to avoid consuming option codes.   Vendor options were never intended for this--vendor options were intended for cases where the vendor doesn't want to take the trouble to document what they are doing, or for cases where what they are doing would be of no interest to others, and hence not *worth* documenting.   There's an implication that vendor options might be used in some cases to do things the vendor doesn't *want* to document.   This doesn't fall into any of those three cases, does it?

So why the sudden push to use vendor options in this way?