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

["Bernie Volz (volz)" <volz at cisco.com>]

We should also keep this in perspective as this is not a 'normal' DHCP
client communicating with a server - it is a leasequery client (NEW
FUNCTIONALITY). And, in some cases, the client may never care to look at
the error code (other than logging it) and thus this works just fine. If
an error code comes back that is a not a 3-digit number followed by a
space, then yes, the code needs to handle that but that is no different
than handling malformed options or other cases where values are not in
the expected range.

As Kim says, if people are concerned about re-using this, we can burn
another DHCP option code (and make it like the DHCPv6 status-code after
which this is modeled but encoded in an existing DHCPv4 error code). The
format is modeled after what FTP, SMTP, POP, and other protocols use
(3-digits, space, text message).

- Bernie

-----Original Message-----
From: Kim Kinnear (kkinnear) 
Sent: Monday, November 02, 2009 11:05 AM
To: Bud Millwood; dhcwg at ietf.org
Cc: Kim Kinnear (kkinnear); Bernie Volz (volz); RAMAKRISHNADTV
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt


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