Re: A counter-proposal for option 127

[Ralph Droms <[e-mail]>]

At 1:55 PM 2/15/96, David Lapp wrote:
>I just took a look at the new IDs for DHCP (Authentication,
>FQDN, and option 127). My compliments on their brevity :-)

Thanks...

>I have a question and perhaps a suggestion for the option 127
>doc.

You and Shawn both discovered the same problem.  See below.

At 1:52 PM 2/15/96, Shawn Mamros wrote:
>I have a problem with the way it's defined, because it violates the
>single-byte option code followed by single-byte length field that
>we've been following to date,

Thanks to both of you for picking up the deviation from the format of the
other options.

>If our esteemed WG chair is willing to entertain a counter-proposal,
>here it is...

Gratuitous flattery aside :-), I think both of you suggested essentially
the same format for option 127; so, it must be the right thing to do.  I
must admit to being appalled at the prospect of 2^16 more options (and the
RFCs needed to define those options!), but I can live with a two-octet
subcode.

There is one difference between your two proposals: Dave suggests wrapping
multiple extended subcodes in one instance of option 127, while Shawn
suggests encoding each subcode option separately.  In the interests of
simplicity, I'd lean towards encoding each separately, but either way is
OK.

How about (from Shawn's message):

    Code   Len     Option      Data...
   +-----+-----+-----+-----+-----+-----+----
   | 127 |  n  |  oh |  ol |  d1 |  d2 | ...
   +-----+-----+-----+-----+-----+-----+----

where "oh" is the high-order byte of the two-byte extended option code,
and "ol" is the low-order byte.  The length "n" must include the two bytes
of the extended option code itself.

- Ralph