Re: What goes around comes around

[Noel Chiappa <[e-mail]>]

    No, I didn't know. Very interesting stuff. Of course, Noel has been
    telling us that he has been talking about his plan for a decade.

Noel didn't quite get the point of this. He will charitably assume it wasn't
meant unkindly, until it is explained.

    There might be another conclusion to be drawn:
     1) the early internet architects already considered infinitely variable
	length addresses in the header (leader).
     2) they thought about how to implement it.
     3) they rejected it.
    Might we not gain from the same insights?

The decision on dropping those happened slightly before I got active in the
Internet Working Group, so I don't know all the reasons why they didn't go
with variable length addresses (although I recall hearing a rumor at the time
involving the number of registers available at interrupt time in TENEX
to hold pointers... :-)

What I *do* know is that nobody, but *nobody*, ever had any idea that IPv4
would *ever* be called upon to support a system of the size we see today. It
was designed as a large scale testbed and trial service system; the initial
address format consisted of an 8-bit network number, and a 24-bit rest! It has
been kludged over the years (first via A/B/C, then subnets, and now CIDR) to
handle a larger system, but we've about reached the end of the road. At this
point, due to a lack of foresight in the design, we are now faced with a
painful and expensive change.

If you think there are any deep insights in the process of designing the IPv4
header which you can apply here, you're very confused. Fixed length addresses
did not contribute in any substantial way to the sucess of TCP/IP, and it
boggles my mind to think that anyone could think so, at least if they hasve
spent any time analyzing why TCP/IP *was* successful.

I'd suggest that the only lesson you can draw from IPv4 is the one I alluded
to above; people put in a quick, simple design which seemed like it was
efficient, and it came back to bite them very badly. Doesn't bode well for
SIP.

    Saying, "I don't think 64-bits are enough", is not a constructive
    comment about the allocation plan, but a comment about "differences
    between the proposals". That is not appropriate for the SIP list. SIP
    is a WORKING group, not a debate society. ... You are confusing addressing
    with allocation. The title is clear. For routing, you should review the
    SIP Routing specification.

It's true that reading the addressing plan document is probably not the best
time to point out problems, but he was just trying to point out something
which, if true, is something I'd think you'd want to know about. However, I'm
not too surprised that you're not interested in hearing about it; it became
clear pretty early on to some of us that the SIP designer(s) weren't
interested in making substantial changes to the design in response to being
told about places where they might have gone substantially off the rails.

Exactly why, I am really puzzled by, since I'd think you all would want to
know about things which would trip SIP up, so you could fix them, but I guess
that brand of logic isn't for everyone. Seems odd to me, though, that people
would put all this time and energy into something, and then condemn it to
failure by making it second-rate. That's human nature for you, though, I
guess; it happens all the time.

	Noel