Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

>>>>> On Thu, 12 Aug 2004 11:31:21 +0200, 
>>>>> Stig Venaas <Stig.Venaas@uninett.no> said:

>> > I too would recommend that this option only be used with stateless
>> > (Information-Request/Reply). It does not apply to stateful - in stateful,
>> > even if there are no T1/T2 times (i.e., no IA_NA option), the client will
>> > need to do something when it no longer has addresses so it will get new
>> > information from the server.

> I think stateless only might be too strict.

> One example I have in mind is:

> If a client sends a request message to obtain addresses and other config
> options and it does not get any addresses but receives other config
> data. Then the client may use those options and not make a
> Request/Information-Request, right?

A quick response for clarification: if you mean the case where the
client receives an Advertise message containing a NoAddrsAvail status
code, I don't think the client may use other configuration options
(moreover, I don't think the client ever receives such configuration
options in this case).

RFC3315 is not so explicit in such a case, but it requires the client
just to ignore such an Advertise message:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.
(Section 17.1.3)

and the server to send minimum information to indicate the error:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
                                       ^^^^
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.
(Section 17.2.2)

Again, this is just for clarification, and may be irrelevant to the
main point of this discussion.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

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