RE: [dhcwg] Stateless DHCPv6 and Elapsed time option ?

Hi:

You mean section 22.9 in RFC 3315. And, yes this does seem to be a
contradiction. However, it is just a "may", not a MAY, in RFC 3736 (section
5.4) whereas it is a MUST in RFC 3315 section 22.9. I also believe that RFC
3315 overrides anything stated in RFC 3736, as 3736 is just trying to
explain the stateless subset of 3315.

As there is little harm in sending the option, send it. If you're
implementing a server, don't discard a client request just because it
doesn't include this option - the option is not that fundamental to server
operation (those fundamental requirements are given in Sectin 15 of 3315). 

In many ways, this option is likely not that important for stateless as
there is very little work a server needs to perform, so it would usually
always respond. One could envision stateful servers where one is a "primary"
and another is a "backup" and the backup might only respond if the elapsed
time has reached some threshold for messages in which there was no server
identifier option?

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Grubmair Peter
> Sent: Tuesday, July 27, 2004 5:32 AM
> To: DHCPV6_WG (E-mail)
> Subject: [dhcwg] Stateless DHCPv6 and Elapsed time option ?
> 
> 
> RFC3315 (DHCPv6), chapter 2.9 says
> a clinet MUST include elapsed time option,
> whereas RFC3736(stateless DHCPv6) chapter 5.4
> says a client may implement elapsed time option.
> Is it correct, if in a statelss DHCP client
> elapsed time option is not sent in Information request ?
> Best regards
>    Peter 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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