dhc wg last call on "DHCP Relay Agent Assignment Notification Option"

> Thomas - one way to think about this option is that it
defines a capability
> that replaces the "snooping" technique that
some devices use to learn about
> the state of DHCP clients.

Kind of what I read between the lines. 

But then, if the purpose of this option is to replace the
snooping
hack, this (or some document -- could be separate) should
explore that
problem space a bit more thoroughly, to make sure we really
are
solving that problem to a degree of reliability that does
solve the
problem good enough. I.e., is this a 99% solution, or only a
60%
solution (compared with the 30% (???? - I'm obviously
guessing)
solution we have in IPv4 today?)

> So, this draft will allow *more* reliable maintenance
of state in a
> network element that needs that state than is available
through
> DHCPv4.

OK. Then document needs to be very clear that the operative
word is
"more reliable", and very specifically,
"NOT totally reliable".

> Perhaps this mechanism could be clarified by stating
more explicitly
> that the Assignment Notification option is usually
piggybacked on a
> message to the client.  In fact, in all the cases I can
think of,
> the Assignment Notification option would always be
piggybacked on a
> message to the client.

I think the keyword here needs to be "always
piggybacked". Even
leaving the door open to having the message go out in other
cases
makes me nervous, because then I fear this is a then the
"nose of the
camel" w.r.t. extending DHC into something it is not
today. This also
gets back to my first point. If it turns out that this
option doesn't
quite solve the actual problem on hand, there will likely be
pressure
to extend DHC just a little bit more to close the gap.

I would be a lot happier if we understood the landscape here
better
before moving forward with this option.

Thomas

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