Subject: Issues regarding server-inituated client configuration (Reconfigure-init) from San Diego

From: Ralph Droms <[email-masked]>
Date: Mon, 05 Feb 2001 11:15:52 -0500

This was originally the first part of a longer message.  I split that long 
message into two shorter messages to encourage prompt response to either or 
(preferably!) both messages.  Please take a quick look at this first 
message and respond with comments (or with an ACK if you think the list of 
issues is accurate and complete).

In the discussion about reconfiguration at the San Diego IETF, the 
following issues were raised:

* Multicast reconfiguration would be a good thing
* Multicast reconfiguration is required in the case
   where the server does not have a complete list of
   clients; e.g., if the server has been
   delivering configuration information but not
   assigning addresses and has not recorded a list
   of clients that have contacted the server
* Multicast reconfiguration requires additional
   consideration of scaling issues to avoid server
   failure in the event of multiple simultaneous client
   responses
* Clients must be made resilient against the receipt
   of multiple copies of a Reconfigure-init message;
   e.g. because there are mulitple relay agents on the
   link or because the Reconfigure-init message
   was duplicated in transit
* There must be an authentication mechanism that is
   compatible with both unicast and multicast to avoid
   denial of service attacks.

Is this a complete list of issues raised in San Diego?
(I'm not sure we raised authentication in San Diego, but
the problem has to be solved...)
- Ralph