[dhcwg] dhcpv6-w4: optional parts of spec

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.

Thomas

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