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

YES! The client MUST include this in the ORO if it is interested in the
parameter. Ted discussed this on the mailing list a few weeks back - that
options really must be in the ORO. And, I do agree with him that this is the
best policy.

If I recall correctly, Ted stated that if a client "wants" an option, it
MUST include it in the ORO.

A server MUST return any options for which it has information if they are in
the ORO. A server MAY include other options that are not in the ORO BUT
there is NO requirement that it must do so.

Note that there are a few exceptions, such as Client-ID, Server-ID, IA_NA,
IA_TA, IAADDR, ... as these are protocol options.

So, by this rule, the client MUST include it in the ORO to assure it gets it
if configured and supported by the server.

- Bernie

> -----Original Message-----
> From: Stig Venaas [mailto:Stig.Venaas@uninett.no] 
> Sent: Friday, August 20, 2004 9:25 AM
> To: Bernie Volz
> Cc: 'JINMEI Tatuya / ?$B?@L@C#:H'; jdq@lucent.com; 
> dhcwg@ietf.org; tjc@ecs.soton.ac.uk
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
> 
> 
> On Fri, Aug 20, 2004 at 08:44:14AM -0400, Bernie Volz wrote:
> > I'm OK to restricting the Lifetime Option to replies to 
> > Information-Request's.
> > 
> > The client MUST ignore a Lifetime Option that is in any 
> message other 
> > than a REPLY to an INFORMATION-REQUEST. A client MUST NOT 
> include the 
> > Lifetime Option number in an ORO except when sending an 
> > INFORMATION-REQUEST message.
> > 
> > The server MUST NOT include the Lifetime Option in any 
> message other 
> > than a REPLY to an INFORMATION-REQUEST.
> 
> Right, sounds good. Thanks for the text.
> 
> This brings up another thing I want to discuss.
> 
> Is it actually useful for the client to include it in ORO at 
> all? Should the server really care?
> 
> I can think of basically three options. I'll be a bit vague 
> on the MAY/SHOULD/MUSTs for now.
> 
> 1. Client may include it. If server sees option it should include
>    it in reply. If server does not see it, it may include it anyway.
> 
> 2. Client always includes it, and server only includes it in reply if
>    client included it in request.
> 
> 3. Client never includes it, and server always or never includes it
>    depending on configuration.
> 
> It would be nice to come to agreement on which alternative is 
> best before trying to formalize things.
> 
> 
> Personally I think alternative 3 makes sense.
> 
> That is, if a server implements the option and is configured 
> with some lifetime by the administrator, then it should 
> always include it.
> 
> If it is not configured by the administrator, then it should 
> not include it, so that clients will just use the default.
> 
> Or do you see a problem with server including the option when 
> client doesn't implement it?
> 
> Stig
> 

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