again: Version 6 Question: Client trying to get new parameters

Gernot Riegert <riegert@nm.informatik.uni-muenchen.de> Tue, 16 April 1996 22:48 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24815; 16 Apr 96 18:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24811; 16 Apr 96 18:48 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa17057; 16 Apr 96 18:48 EDT
Received: from localhost by reef.bucknell.edu with SMTP (5.65/IDA-1.2.8) id AA23784; Tue, 16 Apr 1996 18:45:29 -0400
Date: Tue, 16 Apr 1996 18:45:29 -0400
Message-Id: <Pine.HPP.3.91.960416230110.5604B-100000@hpheger7.nm.informatik.uni-muenchen.de>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gernot Riegert <riegert@nm.informatik.uni-muenchen.de>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: again: Version 6 Question: Client trying to get new parameters
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0

On Fri, 12 Apr 1996 bound@zk3.dec.com wrote:

> Folks this should have come to DHCPv6.
> 
> Gernot,
> 
> >To: Multiple recipients of list <dhcp-v4@bucknell.edu>
> >Subject: Version 6 Question: Client trying to get new parameters
> >X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> 
> >Hello folks,
> 
> >In the latest draft concerning DHCPv6 the way to reconfigure at least one 
> >DHCP client is that the server sends a DHCP Reconfigure message to the 
> >host(s) with the parameters that have to be changed.
> 
> >But what if a client states that some of its parameters aren't valid 
> >anymore? In the draft, I don't see how a client can ask for a new 
> >configuration if the old one doesn't "fit" any more besides cancelling 
> >his connection. So, the client is urged to start a new configuration 
> >process, which is rather superfluous in my oppinion. 
> 
> The reason for the reconfigure is that the clients config is no good
> anymore.  So it has to get it right.  The client may be able to use the
> same address and get an update to the config.  Unless of course they are
> told their address will be deleted.

Thank you very much, but I  wanted to know mainly *how* the client can do 
this? By sending a new DHCP Request? This question isn't answered clearly 
in the draft. 
 
> >A second question: In the description of the DHCP Release message, it is 
> >said that a client might want to release ressources it doesn't need 
> >anymore. What ressources are meant with these words? Could someone give 
> >me an example?
> 
> Another mail gave you an example.  But the resources are any config
> paramters.  Such as an address.

In my opinion, it would be helpful to give examples in the draft if you 
use some terms ("resources") that you don't define before. The text in 
the draft says:

( draft dhcpv6-04: Description of Client processing DHCP Release: )

"If a DHCPv6 client determines that some of its network configuration 
parameters are not longer valid, it may enable the DHCPv6 server to 
release allocated resources ... by sending a DHCP Release to the server. 
The client must consult its list of resource-server associations (what 
does resource-server association mean? it could mean that the client 
picks parts of its configuration from the  various server offers it gets 
and not that it uses only ONE from ONE server - it's only the ambiguous 
formulation) (And by the way, reading the description of the client's 
processing of DHCP Reply, you can't find that this list is created; but 
here the text relates to it)  .. in order to determine which server 
should receive the desired (why desired?) Release message...
..

A client wishes to release resources that were granted to it at another 
link-local adress. (How come? (How) has the client changed its adress? Is 
this a new scenario or does it belong to the preceding text? Again: 
According to the text, it seems to be possible for a client to get its 
configuration from several servers, not only one) In that case, the 
client must instruct ... " (End of citation)

>From this text (and the description of the other proceedings), you can't 
read out what happens to CLIENTS that  want to reconfigure some of their 
configuration parameters because it is only  mentioned that some 
parameters can be released but NOT how a client can initiate a partial 
reconfiguration. This could be necessary e.g. if some network resource is 
replaced by another one with a different adress (Line Printer, DNS 
server, etc.) and the client doesn't want to give up its current lease.

I think I don't have to give the reasons for my questions. But if you 
read the draft in its current version, you MUST come to the conclusion that 
the client *always* has to start a new configuration process for 
reconfiguration of some parameters, which is of course inefficient (tons 
of net traffic instead of one message going to and fro) And if there 
might have been the impression that I'm posing stupid questions: I can 
also *imagine* for myself how the protocol will probably work, but I need 
a *correct* and *exact* definition for working with it.

Thanks and Bye bye

Gernot