It is interesting that people who are omniscient don't appear to
actually understand what is being proposed. Brian has had to repeat
several times that his proposal does NOT alter the standard
autoconfiguration operation.

While I'd not claim to know whether his proposal has sufficient merit to
be accepted, I have a gut feeling that a universal fixed 64 bit boundary
may cause future problems. I also think choice is good, as long as that
choice does not come at too higher "cost". But the proposal must be
understood before the costs can be weighed.

On Mon, 24 Sep 2007, Mark Smith wrote:

> On Sun, 23 Sep 2007 15:42:01 +0100 (BST)
> Jim Jackson <[EMAIL PROTECTED]> wrote:
>
> >
> > I've been lurking for a while, but this illustrates what I've seen in
> > quite a few posts on this list and on the ipv6ops list - some people just
> > know exactly what EVERYONE needs....
> >
>
> I know what my customers want - and I only operate a network because I
> have customers who'll pay me to do it. If I don't know what my
> customers want, I won't have them because I won't be giving them what
> they want. The very large majority of my customers aren't engineers, so
> they don't find technical complexity interesting. They just want it to
> work, and they want it to work as cheaply as it can.
>
> Do a survey if you like. Ask people (not just engineers)
> which option they prefer in any situation, the hard one or the easy
> one. The majority will pick the easy one, and it's usually the simpler
> one.
>
> My customers might not understand what fixed length
> interface ids are. However, what they will understand is that if a 10
> minute job could be made 5, and I spend that saved 5 minutes on
> something else for them that's also a need, they'll say, "we'll go with
> the simpler and cheaper option for this problem."
>
>
> > > So what's best for the IETF's end-users? Simplicity, because it's
> > > cheaper to buy, to configure and to fix. Universal fixed length
> > > interface IDs are simpler.
> >
> > ...and so the inference is that everyone MUST have this option.
>
> Yep, in particular when this thread is trying to change 10 years of
> specified protocol and implementation. It's too late for that.
>
> IMHO, the only way Brian would be able get this changed would be to use
> IPv6 as the basis for IPngng, and start writing IPngng drafts.
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to