>>>>> On Fri, 14 Apr 2006 09:14:58 -0400,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
> I think that trying to codify in the specification differences in behavior
> based on which part of a specification a host implements is
> counterproductive because it adds unnecessary complexity and over-specifies
> the desired behavior. We should describe the behavior assuming an
> implementation of RFC 3315 without qualification. It is up to the
> implementor to decide how to behave if only part of the specification is
> implemented.
> RFC 2461/2 does not make any accommodation for a host that does not
> implement stateless address autoconfiguration as specified in RFC 2462.
> There may, indeed, be such hosts whose intended networking scenario will
> never include stateless address autoconfiguration. Similarly, we don't need
> to add text to the description of the M/O flags to accommodate hosts that
> don't implement parts of RFC 3315.
Now that this discussion seems to vary so much (again), I'm not sure
if it's reasonable to make a response now, especially about specific
wording, but anyway:
In general, I tend to agree that a protocol specification don't have to
(or should not?) care about which part of which protocol is
implemented. In this case, however, we know a subset (RFC3736) of the
full DHCPv6 protocol (RFC3315) has been standardized and (at least to
me) there are pitfalls in the original RFC2461 specification for
nodes that only implement the subset, I think it is worthwhile to be
very specific even if it may sound noisy.
I know not all people are convinced about my concerns, but I think
many people at least see this one confusing:
>>>>> On Thu, 13 Apr 2006 17:37:45 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Secondly, I'm not sure what a host that only implements DHCPv6lite
> (and not the other part of RFC3315) should do when it receives an RA
> with the both M and O flag being on. Such a host may be just fine
> with link-local addresses or with addresses configured in some other
> way, and may simply want to get other configuration information by
> DHCPv6lite. I believe it's a valid scenario, but the current proposed
> text is not clear on this to me.
It's not clear to me, and I believe it's also unclear to other future
developers. Moreover, it's not only unclear but also may cause
interoperability problems in that DHCPv6lite-only nodes may not be
able to perform the operation in this case, depending on the details
of the semantics.
Qualifications like "that implement DHCPv6 [RFC3315]" may sound
awkward and/or redundant for some people, but I believe at least they
don't harm. And the qualifications will surely clarify things for
some other people (it works for me at the very least). So, I still
prefer my proposal than the original one (if we need to choose either
of these two).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
