[dhcwg] dhcpv6-w4: optional parts of spec

Thomas Narten <narten@us.ibm.com> Wed, 15 May 2002 16:59 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13309 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 12:59:18 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12353 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 12:59:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11541; Wed, 15 May 2002 12:49:02 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11523 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 12:49:01 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12921 for <dhcwg@ietf.org>; Wed, 15 May 2002 12:48:46 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FGlar01969 for <dhcwg@ietf.org>; Wed, 15 May 2002 12:47:36 -0400
Message-Id: <200205151647.g4FGlar01969@cichlid.adsl.duke.edu>
To: dhcwg@ietf.org
Date: Wed, 15 May 2002 12:47:36 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-w4: optional parts of spec
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

From another thread:

Ted Lemon <Ted.Lemon@nominum.com> writes:

> > Hmm. If this message is OPTIONAL to implement, this needs to be made
> > clear in the spec. I assumed it was mandatory. I think it should be
> > mandatory. If it is not, there is little point in clients implementing
> > it. I.e., it doesn't make sense for clients to implement basic
> > features that servers aren't required to implement. This leads to bad
> > interoperability.

> This is a case where the market will quickly punish servers that don't 
> implement it that should.   We aren't even insisting that address 
> allocation is mandatory, AFAIK, so saying that confirm is mandatory seems 
> inconsistent.   That is, it is fine to implement a DHCPv6 server that only 
> responds to information requests and that does not allocate IP addresses.   
> A DHCP server configured to just provide information might not even have 
> enough information to determine whether or not a client is on the link on 
> which its addresses are valid.

I have a real problem with significant parts of the base DHCP being
"optional" Note also that an IESG reviewer (independently) did notice
the following:

> 1.2. Protocol implementation

>    Clients and servers that do not use all of the functions of DHCP
>    need not implement processing for those DHCP messages that will
>    not be used.

> how will this ever do *useful* interop testing?  a client/server
> pair which implement *no* messages, or a useless but amusing
> subset, could pass.

If we want useful interoperability, that means that any protocol
feature the client MAY (or even SHOULD) be able to implement MUST be
implemented by the server. Note I am not talking about support for
individual options. But I am talking about support for basic DHC
message types (Confirm, Fast-Reply, etc.)

I think the spec needs to make it very clear that all parts of DHC
MUST be implemented for a server to be considered compliant.

If the WG wants to define several levels of implementations (like a
non-address supporting mode) that is one thing. But then the document
should make it clear what parts MUST be implemented in order to be
support a particular mode. But life would just be simpler if the spec
just said servers need to implement everything.


dhcwg mailing list