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

[Kim Kinnear <kkinnear at cisco.com>]

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.


>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