![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> I'm being a bit extreme but the point is that just because something is
> architecturally bad doesn't mean you shouldn't do it, since these days it
> takes us years to make any architectural enhancements.
perhaps architectural impurity alone shouldn't keep you from doing something, but the fact that something violates fundamental design assumptions should cause you to do some analysis and hard thinking about the likely consequences of using them.
and if you are in the business of selling boxes that violate the design assumptions you shouldn't misrepresent these to your customers.
Sounds like we have some agreement on the list.
most of these hacks can be employed in ways that are mostly harmless, but knowing when they are harmless and when they will cause harm can be quite difficult.
NATs seemed mostly harmless when they were first deployed; now they're a huge problem.
Just wait until mobile IP-based "phones" take off!
...Scott
__________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.