>>>>> On Fri, 23 Apr 2004 23:24:19 +0200,
>>>>> Iljitsch van Beijnum <[EMAIL PROTECTED]> said:
>> Some people commented that we needed to clarify what's bad with the
>> M/O flags if we want to deprecate (or remove) them.
> You only discuss "what would break if we deprecate these flags". I have
> no problems with the text that follows, but I DO have a very big
> problem with changing these flags. You can't just go around and change
> protocol specifications every few years just because it looks better
> that way.
Sorry, I don't understand the comment...I still have a feeling that I
see an attempt to impose a negative impression on a concrete proposal
based on a practical analysis by making a general comment that no one
can disagree.
It's probably true that "you (we) can't just go around and change
protocol specifications every few years just because it looks better,"
but how does this apply to my proposal?
I tried to describe what is wrong with the current specification,
tried to describe what can be broken by deprecating the flags, and
tried to explain the breakage won't be a problem in a practical sense
(at least IMO). If this discussion is convincing but still can be
regarded as "just saying it looks better that way", can't we ever
deprecate anything? For example, if we can buy this kind of argument,
how could we deprecate site-local addresses?
Also, what do you mean by "every few years" in this particular
discussion? RFC2462 was published in 1998, and we are now trying to
make the specification clearer, fixing known problems and clarifying
the details based on 5-6 years of experience. Are you saying this
activity as "changing protocol specifications every few years"?
Honestly, I'm willing to withdraw the proposal if someone makes a
concrete, convincing couter argument...but, yours seems too
general, abstract, and unfair (sorry, I can't find a better word) to
convince me on this particular topic.
(But I don't think this paragraph is your main point, and if I'm
correct, let's just focus on the rest of your message)
> Besides, NOW is certainly not the time to do it, as DHCPv6 is finally
> there, but hasn't seen much if any real-life experience yet, and
> additional "other configuration" mechanisms are still under discussion
> for at least one very important configuration item: recursive DNS
> server addresses.
So are you proposing to keep the flags but leave the semantics (e.g.,
what the "stateful" protocol is) unclear as currently is? If so, I
disagree for two reasons.
First, it will easily cause confusion and interoperability problems to
leave it unclear. In fact, we have seen the confusion due to the
unclear specification since RFC2462 (or even since RFC1970), and this
is exactly the reason why we are now trying to clarify this point.
Secondly, if the situation is that immature, why can't we simply
deprecate the flags for now and leave the flexibility for future
extension? This way, we can clearly avoid confusion due to the
unclear specification and the misuse of the flags based on the
confusion, as well as leave the possibility to adopt the best way as
the situation becomes mature. We'll even be able to revive the same
flags at that time.
> I implore this wg to venture out into the real world and ask operators
> what they need to be able to use IPv6 rather than regurgitate the same
> RFCs over and over. This goes double for v6ops.
A general comment, again...so what exactly are you proposing for this
particular issue? Even though main subscribers in this list are
implementors, I'm quite sure that we also have many operators here.
In fact, I'm running IPv6 networks of my own. I also know operators
working for major ISPs subscribe to this list. And I'm asking
everyone in this list, including operators of course, on this issue.
If you're requiring to bring this discussion to the v6ops wg and ask
them what they think, that's fine. But I'm quite sure many vocal
members there subscribe to this list as well.
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
--------------------------------------------------------------------
