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

[Kim Kinnear <kkinnear at cisco.com>]

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.

        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.

        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.


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

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

        Thanks again for your comments, truly!

        Kim

> UTF-8 encoding was created 
>as a superset of ASCII. It seems possible.
>
>>       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
>
>>
>> >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