Folks,
> It may well have been responsible for the
> great popularity of Ethernet and its followons. ... I don't understand
> the suggestion that it was "shortsighted".
...
The thing that's true is that ARP contains basically zero security.
...
> I would also point out that ARP was thought-forward enough to
support other
Well, this is a better sequence of notes than I had hoped for, given
that it reflects exactly the line of meta-issues I meant to suggest.
My own summary:
ARP is simple and specific. It solves a particular problem -- albeit a
very constrained one -- quite nicely. It has a specific bit of
flexibility, but really only a small amount. The flexibility has been
quite useful, but overall functionality of arp is pretty rigid.
It most certainly would have been possible to envision all sorts of
more-general mechanisms. One might have killed the arp development
effort, in favor of the more general effort.
Luckily, narrow, short-sighted design thinking carried the day.
We have developed a tendency in the IETF to fail to distinguish between
"it won't work" and "it could/should work better". Worse, the latter
tends to reflect idealism from those who are tasked neither with doing
the work nor delivering the output to the market. So they tend to
assert their views with great force but no balance against delay/benefit
trade-offs.
"It won't work" must be a show-stopper. It is valid to assert it at any
time, of course.
"It could/should work better" is always reasonable to express, almost
never appropriate for that assertion to be the basis of stopping forward
progress. During the actual design process, it is of course appropriate
to try to recruit rough consensus for a superior design. But
recruitment efforts are not the same as blocking efforts.
When a constituency comes to the IETF, trying to solve a problem, they
represent a portion of the market that is motivated for near-term output.
What has become the norm in the IETF is to impose massive startup costs
for the working group, massive commentary-documenting costs in the
writing, and open-ended delay in trying to satisfy every demand of every
person who expresses unhappiness with any aspect of the work, at any
point in the process.
The IETF used to *facilitate* collaboration on timely specifications.
One of the ways it achieved was to distinguish between technical failure
and technical preference.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf