Re: [dhcwg] draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt

[Bud Millwood <budm at weird-solutions.com>]

On Monday 02 November 2009, Kim Kinnear wrote:
> Bud,
>
> A couple of comments, preceded by Kim:
>
> At 04:18 AM 11/2/2009, Bud Millwood wrote:
> >Well thanks for your patience; I'm jumping in here at the last minute (as
> >usual) and not articulating myself particularly well.
> >
> >My comments are inline, preceded by 'Bud:'.
> >[...]
> >I would say that subclassing an integer from a string does make me
> > slightly ill.
>
>         Oh darn, if only I'd use three character letter codes for
>         the various status codes, I don't think we would be
>         having this conversation.
>
>
>         So let me try that one more time -- what if, instead of
>         characters that translate into numbers, we simply said
>         that in the context of bulk leasequery, the first three
>         characters MUST be one of an accepted set corresponding
>         to various status codes.  And we fix the status codes to
>         have alphabetic "codes" instead of numeric ones so people
>         don't get confused with what we are tying to do.
>
>         If that doesn't work for you, we'll just burn another
>         option code.

Somehow we got stuck on this little issue, and it's not that important. Plus 
Bernie pointed out that it's more common than I realized, so let's leave it 
as it was.

As for subencoding standard options (below), it's something I find very 
interesting, but I'm sure we'll all jump off that bridge when we come to 
it. :)

- Bud

> >Bud:
> >I was thinking about the fact that we are short on option numbers.
> >
> >In my world, suboptions are processed very much like top-level options, so
> > it seems reasonable to simply declare a new subencoded option with, say,
> > tag 254 and declare that when we run out of top-level option numbers, we
> > will start declaring rfc-standard dhcp options inside option 254. That
> > was my train of thought. Not directly related to bulk leasequery, but
> > then again indirectly related to any proposal that requires an option
> > code.
>
>         While this is certainly possible, and may well be the
>         choice when we truly run out, I believe that processing
>         such options is intrinsically more complex than
>         processing normal, first-class options.  There are a lot
>         of issues to work out, not least the fact that many
>         servers give users the ability to define custom options.
>         Defining custom options which are sub-encoded is just
>         that much more complex for users.  In addition, there are
>         various difficulties in dealing with sub-options that are
>         really first class options -- but that exist in a
>         sub-option name (number) space.  Issues that can
>         certainly be worked out, of course, and are not all that
>         hard to deal with.  Still, these all need to be specified
>         in detail, and code has to be written in a number of
>         servers in the same way in order to make all of this
>         work.
>
>         So, while conceptually simple, I think most folks would
>         like to avoid this as long as possible.  Maybe forever.
>         I know that I would!
>
>         [In large part because the code to do all of this
>         provides *no* ultimate value or increased capability to
>         the end-user except indirectly through the increase in
>         option space.  Which is why I'm trying to conserve said
>         option space.]
>
>         But if you don't like the three character status codes,
>         we'll burn an option for this and that will be that.
>
>         Cheers -- Kim
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687