Subject: [dhcwg] DHCPv6 Elapsed Time

From: "Andre Kostur" <[email-masked]>
Date: Tue, 28 Nov 2006 09:39:49 -0800

Do I read section 22.9 correctly in that all client-initiated exchanges
MUST supply an Elapsed Time option?

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Damien Neil <[email-masked]>
Date: Tue, 28 Nov 2006 14:59:49 -0800

> MUST supply an Elapsed Time option?

This is my interpretation.  I would expect a server to be liberal in  
accepting messages that don't include this option, however.

               - Damien

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 28 Nov 2006 15:12:34 -0800

> -----Original Message-----
> From: Damien Neil [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 3:00 PM
> To: [email-masked]
> Subject: Re: [dhcwg] DHCPv6 Elapsed Time
> 
> > Do I read section 22.9 correctly in that all client-initiated 
> > exchanges MUST supply an Elapsed Time option?
> 
> This is my interpretation.  I would expect a server to be 
> liberal in accepting messages that don't include this option, however.

But with that interpretation the server has no room to be liberal in
accepting the messages.  That's a MUST, not a SHOULD.

---

From: Damien Neil <[email-masked]>
Date: Tue, 28 Nov 2006 15:18:56 -0800

> accepting the messages.  That's a MUST, not a SHOULD.

I don't believe there is any language in 3315 that requires a server  
to reject messages that don't conform to 3315.  The fact that a  
client message that doesn't include an Elapsed Time option is in  
violation of the standard doesn't mean a server can't attempt to  
handle it.

                 - Damien

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 28 Nov 2006 15:47:56 -0800

> Sent: Tuesday, November 28, 2006 3:19 PM
> To: Andre Kostur
> Cc: [email-masked]
> liberal in 
> I don't believe there is any language in 3315 that requires a 
> server to reject messages that don't conform to 3315.  The 
> fact that a client message that doesn't include an Elapsed 
> Time option is in violation of the standard doesn't mean a 
> server can't attempt to handle it.

Isn't that what RFC 2119 is for? :

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Why isn't that a MAY in s22.9 instead of a MUST?

Actually, it does contain wording in s15 (granted it doesn't specify
rejection, but does suggest a response):

   If a server receives a message that contains options it should not
   contain (such as an Information-request message with an IA option),
   is missing options that it should contain, or is otherwise not valid,
   it MAY send a Reply (or Advertise as appropriate) with a Server
   Identifier option, a Client Identifier option if one was included in
   the message and a Status Code option with status UnSpecFail.

My interpretation would be that the server has two options.  1) The
incoming packet isn't DHCPv6, so ignore it, or 2) Send back an
UnSpecFail as mentioned in s15.

I guess the real question is whether s22.9 should be a MAY instead of a
MUST.

---

From: Damien Neil <[email-masked]>
Date: Tue, 28 Nov 2006 19:06:34 -0800

>    definition is an absolute requirement of the specification.

This indicates that a client which fails to send an Elapsed Time  
option in a DHCPv6 message is in violation of RFC 3315.  It doesn't  
indicate what a conforming DHCPv6 server may do with such a message.

> Why isn't that a MAY in s22.9 instead of a MUST?

Because a client must send the Elapsed Time option in order to  
conform to the specification.

> UnSpecFail as mentioned in s15.

I don't see any language in 3315 that indicates that a conforming  
server is limited to these two options.  The behavior of a server  
upon receiving a non-conforming message is largely unspecified-- 
which, I strongly feel, is appropriate.  In the real world, most  
servers will regrettably find themselves obligated to interact with  
non-conforming clients on occasion.  It would be unfortunate to make  
such interaction, in cases where it does not impact conforming  
clients, a violation of the standard.

As Jon Postel said: "Be liberal in what you accept, and conservative  
in what you send."

There are times when it can be a vice to be too forgiving of errors  
in client input.  Personally, I don't believe that this is such a  
case, although you are certainly free to disagree.  I firmly believe,  
however, that a server which chooses to overlook a broken client's  
failure to include this option is not itself in violation of 3315.

> I guess the real question is whether s22.9 should be a MAY instead  

I can't see any reason why it should be.

                      - Damien

---

From: Damien Neil <[email-masked]>
Date: Tue, 28 Nov 2006 14:58:56 -0800

- Damien

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Nov 2006 22:54:17 -0600

> I guess the real question is whether s22.9 should be a MAY instead of a
It should not.   The reason that it's MUST and not SHOULD or MAY is that 
we want to be able to know how long the client's been trying to contact 
the server.   If the client doesn't send this option, we don't know.   
It's always ultimately up to the implementor how to deal with a 
non-conforming client, but certainly a conforming server should, as you 
say, either drop the packet or send back a failure code.   But generally 
speaking, if we implement servers that accept packets without the 
elapsed time option, then we can expect to see clients implemented by 
people who aren't very good about interoperability testing that do not 
send the elapsed time option.   I would say that at least by default 
it's better if the server in fact drops the packet, although I don't 
think there's any harm in having a configuration option that, when set, 
instructs the server to be more permissive.