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

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

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
> >> 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
> >_______________________________________________
> >dhcwg mailing list
> >dhcwg at ietf.org
> >https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> 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