>>>>> On Thu, 18 Mar 2004 09:45:12 -0500,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
> For the IPv6 WG - let's cut to the chase. Is there interest in expending
> any more of the IETF's resources reopening a problem for which we
> have rough consensus on a solution, published specifications and running
> code? We have lots of important problems that have *no* solution, yet;
> let's move on to those problems and start deploying the solutions we already
> have completed.
I basically agree, especially in that this thread won't be productive
enough to spend everyone's energy.
Just to state my own opinions on some discussion points:
- whether (implementing) DHCPv6 is too complex for the purpose of
prefix delegation.
I'm reluctant to have this discussion, since this kind of discussion
often tends to be a subjective one. I personally don't think the
spec is "too" complex from my experience of reviewing and
implementing the document, but it would be difficult to prove my
impression.
For example, I needed three days to implement (an initial version)
the prefix delegation mechanism using the "IA" based resource
management, which corresponds to the core part of the DHCPv6
specification. Two weeks later (since then I had made some bug
fixes and additional features to the initial implementation), I
confirmed the interoperability of the implementation with several
other vendors. Can this fact be a proof that the specification is
"not to complex to implement"? May be not, particularly for those
who do believe the complexity from the beginning...
I also know several vendors that provide "cheap" CPE devices,
including Yamaha, 6Wind and Allied Telesis (some of them may not be
popular outside Japan), have implementations of prefix delegation
based on DHCPv6. Do we really want to provide (yet) other
candidates due to the "complexity" even with this fact? Probably
yes, those who do believe the complexity...
- whether it is a good thing to provide other (new) possibilities. Of
course, having alternatives is in general good. In this particular
case, however, I don't see the need for it. First, as already
stated, I don't think the "complexity" (if any) can be a
show-stopper of IPv6 prefix delegation. In fact, (again as already
stated) even vendors who would want a "simpler" specification have
already implemented the specification.
On the other hand, having several choices would increase
implementation/operational cost. Vendors will end up implementing
both (or all) of them, considering possible combinations. Operators
will often have to learn how to configure the devices for all
mechanisms (because in general we cannot assume a particular
behavior at the other end). These kinds of issues are not new or
specific to prefix delegation; it's basically a trade off issue.
But, IMO in this case, I don't think the advantages of flexibility
outweigh the disadvantages of the cost.
In any event, I don't know how we can go about this discussion. As
we've seen (or as far as I've seen), the points are quite subtle
and/or subjective and it will be difficult for any party to convince
the other. One thing I'm quite sure is that it will be a waste of
time to continue the discussion here (whether the "simpler" mechanism
is a good idea or not).
So, I'd like to propose:
1. let's just stop this thread now. On top of this,
2-1 if those who want to standardize the "simpler" mechanism can
continue the work as individual, let them do it, and let "the
market" decide. If the market likes the "simpler" idea, vendors
will start implementing it and operators will start deploying it.
Then we can consider to take it as a wg item and/or publish it as an
RFC, etc.
2-2 if those who want to standardize the "simpler" mechanism stick to
adopting it as a wg document, then I don't know what to do. But
we'll at least need to see consensus to adopt it. And, with all due
respect (I'm trying to be fair as much as possible), the idea has
not attracted many people.
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
--------------------------------------------------------------------
