![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> 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. 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. Keith
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.