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

From: Bud Millwood <[email-masked]>
Date: Mon, 2 Nov 2009 10:18:55 +0100

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:'.

> Bud,
>
> Thanks for your comments.  I've removed the things on which we
> agree (and I certainly appreciate those comments too).
>
> My comments on your comments on my comments (whew!) are preceded
> by Kim:
>
> At 08:26 AM 10/27/2009, Bud Millwood wrote:
> >On Monday 26 October 2009, Kim Kinnear wrote:
> >>       Given that we are moderately short of options in the
> >>       global DHCP option space (though less than we once were,
> >>       of course), it seems wasteful to define a new option for
> >>       use in bulk leasequery when we can use an existing option
> >>       simply by more closely specifying the values that it may
> >>       contain.
> >
> >Hmm, both arguments seem reasonable.
> >
> >But I have to wonder, is this now our standard operating procedure for
> > DHCPv4, to always overload options just because it's technically
> > feasible?
>
>         Kim: No, of course not.  Just when it seems to make some
>         sense.
>
>         I think it is worth looking at the specifics of what is
>         being proposed first, and considering metaphors of
>         uncertainly congruity second (or even later) when
>         examining questions such as this.

Bud:
I tend do the opposite, first searching for systematic metaphorical coherency 
in an attempt to keep design and implementation to an absolute minimum. But I 
*promise* not to get started on George Lakoff's work on this mailing list. :)

>         My test is: does what is proposed make you slightly (or
>         severely) ill?  If so, let's not do it.
>
>         Personally I find this a bit unusual but overall quite
>         reasonable.
>
>         Were I look for a metaphor for this particular proposal,
>         I would say that we were more or less sub-classing the
>         message option for use in a specific and limited context.

I would say that subclassing an integer from a string does make me slightly 
ill.

>         One nice feature of this is that all extant packet
>         sniffers should need no changes to process this (though
>         that wasn't why we thought it up).  They'll need
>         plenty of changes to process TCP based DHCP traffic,
>         I expect, so this isn't a big sales approach.
>
>         But if you (or you all) can't stand this on its own
>         merits, we'll change it to use a new option and be
>         done with it.

Bud:
I would prefer a new option.

> >On a side note, why is it difficult to expand the DHCPv4 option space?
>
>         I'm must be misunderstanding something here.  There is a
>         256 byte type code, and while we tried to make it bigger
>         years ago, that effort languished.

Bud:
I don't recall that effort.

> >Subencoded options are in their own number space.
>
>         For sure, but we aren't in a sub-option situation here.
>
>         But I think I've lost the train of your thought.  Maybe
>         you could help me understand what you mean here?

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.

> >>       We discussed the optional possibility for this
> >>       a long time ago.  Some servers support such a
> >>       thing, and it seemed valuable to provide for it,
> >>       but we can certainly take it out.
> >
> >We support grace periods, but I fail to see how this information of use to
> > a relay agent. Is there something the relay could use this information
> > for that would result in some increase in effectiveness or efficiency?

Bud:
There are no official standards for "grace period"; our grace periods 
dynamically change based on server conditions, for example. No telling how 
that could cause problems. It seems prudent to not expose grace periods 
unless it's absolutely required, and then only after it has been thoroughly 
described in a standards document.

- Bud

> >
> >- Bud
> >
> >> >Section 10:
> >> >
> >> >As I mentioned earlier, the only authorization model for this protocol
> >> >is based on the requestor's IP address, and there is no
> >> >authentication.   At a minimum this should be mentioned in the
> >> >security considerations section.
> >>
> >>       There was a much better security section in RFC4388,
> >>       which I transplanted here.  While it may not be everything
> >>       you wanted, it is certainly better.
> >>
> >> Thanks much to both of you for your input!
> >>
> >> Regards -- Kim
> >>
> >> _______________________________________________
> >> dhcwg mailing list
> >> [email-masked]
> >> 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
> >_______________________________________________
> >dhcwg mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> 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

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 02 Nov 2009 11:05:26 -0500

Bud,

A couple of comments, preceded by Kim:

At 04:18 AM 11/2/2009, Bud Millwood wrote:
>[...]

        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.

>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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 Nov 2009 10:43:35 -0600

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; [email-masked]
Cc: Kim Kinnear (kkinnear); Bernie Volz (volz); RAMAKRISHNADTV
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt

Bud,

        Cheers -- Kim

---

From: Bud Millwood <[email-masked]>
Date: Tue, 3 Nov 2009 09:52:44 +0100

On Monday 02 November 2009, Kim Kinnear wrote:
> >I would say that subclassing an integer from a string does make me
> > slightly ill.
>

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

> >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.
>