On Wed, 7 Jan 2004, Brian Haberman wrote: > > I think that would appropriately encourage implementation of > > the Token-bucket method without invalidating existing > > implementations that use one of the others. > > I agree with the sentiment here. Changes to this document should > not affect backwards compatability. So, I would be opposed to > making the proposed change unless we can determine that noone has > implemented the timer-based or bandwidth-based mechanisms.
Timer-based methods have, unfortunately, been implemented and deploying. IMHO, those should definitely be changed, but I have some sympathy for those who see this as something like "yeah, it's broken, but we don't care about this strongly enough to make them fix it." Remember that in the current text, we're talking about *examples* of possibilities to implement the rate-limiter. We'd just be removing bad examples, and probably adding some non-normative text on why token-based mechanism is recommended. This might be a different situation if we said that token-based rate-limiting MUST be implemented.. but at least I'm not arguing for going that far. As for the different values of token-bucket (or timer-based, or whatever) mechanisms, I'm not sure if that matters that much, it could be an implementation detail as long as it's reasonable. At most one could give a "SHOULD be at least XXXX" implementation hint.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
