>>>>> On Fri, 20 May 2005 13:47:25 -0400,
>>>>> Thomas Narten <[EMAIL PROTECTED]> said:
> That is, vendors always implement additional knobs/whistles as they
> see fit. The IETF doesn't need to account for all of those.
> What we our specs do need to support is not disallowing behavior that
> it might make sense to allow for, and that doesn't negatively impact
> interoperability and such.
> The above should be perfectly consistent with our existing specs. Do
> you (or others) feel otherwise? I.e., is the above not allowed by our
> specs?
(Perhaps it's not wise to continue this thread while we are in the
separate "meta" thread, but)
I believe we've basically agreed on each technical point (e.g.,
whether a host can perform DHCPv6 based on its decision/policy even if
the corresponding M/O flag is off; the answer is "it can"). The real
point in this thread is, at least to me, as follows:
It's the fact that people have actually been confused about these
points. We now know the answers to the questions, but I'm quite sure
new implementors will ask the same questions in the future, since most
of the background rationale is implicit, e.g., "this is valid since no
specification explicitly prohibits it", and we'll continue answering
the questions by saying "yes, it's valid because no specification
explicitly prohibits it".
I don't know if such confusion is just usual in the IETF
specifications or there is something special for the M/O flags and
DHCPv6 case, due to, for example, partly overwrapping functionality of
"Host Configuration Behavior (full RFC3315)" and "Configuration
Information Behavior (RFC3736 subset)" or other complexity you
mentioned in the other thread.
I personally think this is the latter case, and it makes sense to
clarify these points explicitly in order to help future implementors
(and ourselves by avoiding seeing/answering the same questions again
and again). If I don't misunderstand him, Ralph also seems to think
some clarification is useful.
On the other hand, you and some other guys seem to regard this as a
usual case which does not require explicit clarification. If this
group is the majority, I won't fight against it; at least I now know
the answers to the questions, so (hopefully) I won't be confused any
more:-)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
