Re: [dhcwg] Leasequery: should it be standardized?

... A little late, but ...

Definitely, we should proceed with it.  It's currently in use in a 
number of places.  I know our own cable modem code uses it.  We've also 
heard customers describe network designs where it would come in useful.

Just my $0.02.

/raj

On Wednesday, February 26, 2003, at 09:36  AM, Kim Kinnear wrote:

>
> Folks,
>
> We have come to something of a impasse on the leasequery draft,
> and I need *your* support if you believe we should continue to
> pursue this draft.
>
> ===============================================================
> Without considerable support from the DHC WG, we will halt work
> on the leasequery draft and all attempts to bring this work to
> standard status.
> ===============================================================
>
> If you believe that there is any value in standardizing the
> leasequery capability, please at least respond to this list ASAP
> with your positive support.
>
> If you have the time and expertise, please read the rest of this
> email and see if you can offer cogent arguments as to why this is
> work that the DHC working group should be pursuing.
>
> If we don't standardize the leasequery capability, each vendor of
> access concentrators and DHCP products that wish to use this
> approach will then need to work together (possibly in some other
> forum) to try to get their products to be compatible.  Of course,
> it may well be that we are the only folks who see this as a
> useful capability, and so that may not be an issue at all.
>
> Thanks -- Kim
>
> -----------------------  Summary -----------------------
>
> In case you haven't been following the email between Thomas
> Narten and myself, he has been questioning the problem statement
> of the leasequery draft.  Ralph proposed a new problem statement,
> but Thomas feels that this whole capability is questionable.
>
> You are invited to respond to Thomas' arguments, which I have
> distilled as follows:
>
>   1.  Doing anything in the DHC WG like supporting "access
>   control in router type devices" is out of scope for the working
>   group, and doesn't fit its current charter.
>
>   2.  Access control in router type devices is not well enough
>   understood to be sure that:
>
> 	a) leasequery is the right solution.
>
> 	b) any DHC-based approach is the "right" approach to
> 	solve this problem.
>
>   3.  Until we are sure of 2(a), then we should not proceed with
>   this work (I believe that this statement is implicit in Thomas'
>   comments.)
>
> -----------------------  Background ---------------------------
>
> Here is Ralph's proposed problem statement:
>
>    Router-type devices which want to enforce some level of access
>    control over which IP addresses are allowed on their links
>    need to maintain information concerning IP<-MAC/client-id
>    mappings.  One way in which these devices can obtain
>    information about IP<-MAC/client-id bindings is through "DHCP
>    gleaning", in which the device extracts useful information
>    from DHCP messages exchanged between hosts and DHCP servers.
>
>    However, these devices don't typically have stable storage
>    sufficient to keep this information over reloads.  There may
>    be additional information that is useful to the device that
>    cannot be obtained through DHCP gleaning.  The leasequery
>    request message described in this document allows a device to
>    obtain information about IP<-MAC/client-id bindings from a
>    DHCP server.  This information may include currently active
>    bindings, bindings involving previously assigned addresses for
>    which the lease on the address has expired and static bindings
>    for devices that are otherwise configured and not using DHCP
>    for address assignment.
>
> Thomas' concerns center on the second paragraph above, and he says:
>
>    Note, that above is pretty vague and doesn't say what
>    information the access device needs.  It's hard to look at the
>    problem statement and say "yes, I understand the boundaries of
>    the problem" and then "and the solution seems like a good
>    match for the problem".
>
>    Popping up a level, how is it even appropriate for the DHC WG
>    to be doing work on "access control in router type devices"?
>    One can argue that work of this broad a scope is well
>    out-of-scope for this WG (e.g., look at the recently approved
>    charter).  I'm far from clear that work of this scope should
>    be done in DHC or that the problem is well enough understood
>    to conclude that DHC lease query is the right solution or that
>    any DHC-based solution is the right one.  What about routers
>    wanting to do access control that don't use DHC, for instance?
>
>    And note, I'm not raising these issue just to be a PITA. These
>    are questions that I expect that the IESG would ask if I
>    brought the document forward.  Thus, I need to have reasonable
>    responses to those questions.  Otherwise, I can predict the
>    likely outcome.
>
> My response to Thomas was:
>
>    This approach to access control was developed by joint work
>    with the folks building our access concentrators and several
>    of us in the DHCP implementation group.  They found that the
>    functionality delivered to actual users was of sufficient
>    value to those users to be worth the cost of engineering this
>    particular solution.  We supported them in moving the
>    implementation forward.
>
>    The solution was not based on the charter of the DHC working
>    group either then or now -- it was based on a rather pragmatic
>    approach to meeting the needs of users, which it has seemed to
>    do.  In my view at least, it fits within spirit of the DHC WG
>    activities, and was a logical extension of the those
>    activities.
>
>    It isn't a comprehensive approach to any sort of security (nor
>    was it designed to be such) -- it is a supporting piece of
>    technology to one limited form of access control.
>
> Thanks for your interest in the leasequery capability.
>
> Kim
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg