Subject: [dhcwg] dhcpv6-w4: optional parts of spec

From: Thomas Narten <[email-masked]>
Date: Wed, 15 May 2002 12:47:36 -0400

From another thread:

Ted Lemon <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2002 12:36:46 -0500

> just said servers need to implement everything.

I don't feel very strongly about this, but we did have a last-call 
objection to the protocol because someone wanted to have a simpler protocol 
for just getting information, and didn't want to have to implement the 
whole thing (indeed, argued that the whole thing wasn't useful, but that 
the partial implementation was).   Do we just ignore that comment?   Can we 
ignore it and get through last call?

What about clients?   Do we say that a client that only implements the 
information request/reply sequence isn't compliant?   Is a client that 
doesn't implement fast commit non-compliant?   What about a client that 
doesn't implement certain options?