Fred, I mostly agree with Pekka here.
Specific comments inline: > > I think we may have glossed over this in earlier discussion, > > but I believe > > 'B' should be allowed as an expression of either messages OR bytes. > > Size *does* matter in certain cases, and expressing 'B' > only in terms > > of a number of messages is too limiting. I think this can > be fixed rather > > simply by changing the phrase: "B error messages" to > > "B error messages/bytes". I agree with Pekka that this compllicates the text and the implementation. Moreover, N (the long-term average) can be in number of packets per seconds or a fraction of the attached link's bandwidth. Don't you think, the size of the packet will be covered if N is specified as the fraction of the bandwidth ? > > Rate-limiting mechanisms which cannot cope with bursty traffic > > (e.g., traceroute) are not recommended; thus a simple timer- > > based implementation, allowing an error message every T > > milliseconds (even with low values for T), is not reasonable. > > > > I don't see the purpose in dis-recommending a particular scheme, > > (i.e., the simple timer), since there are infinitely many other > > possibilities that would be equally bad (or worse). Suggest > > shortening this paragraph to a single sentence such as: > > IMHO, it makes sense to dis-recommend an approach, because it's > actually deployed out there, and thus it seems to be a good idea to > specifically say that it is NOT a good idea. I'm not aware of other, > "really broken" mechanisms which would have been deployed. Moreover, > this was suggested in the previous RFC, so recommending against it > explicitly seems like a good idea. Agree. We even considered removing it. So dis-recomending is softer than that. > The text could use a bit sharpening up, to say that timer-based > discouragement is just and example, though, like: > > Rate-limiting mechanisms which cannot cope with bursty traffic > (e.g., traceroute) are not recommended; for example, a simple > timer-based implementation, allowing an error message every T > milliseconds (even with low values for T), is not reasonable. Sounds better. > > The rate-limiting parameters SHOULD be configurable. In the > > case of a token-bucket implementation, the best defaults depend > > on where the implementation is expected to be deployed (e.g., a > > high-end router vs. an embedded host). For example, in a > > small/mid -sized device, the possible defaults could be B=10, > > N=10/s. > > > > I may have missed this in earlier discussion, but the "SHOULD" > > above used to be a "MUST" in the earlier text - is there any reason > > we are now saying "SHOULD" instead of "MUST"? > > I thought that was appropriate due to the reasons listed in the mail > where I proposed the text. I do not think it makes sense to require > the values MUST be configurable on every kind of device -- take e.g. a > mobile phone which implements an IPv6 stack. MUST seems too strong > here. SHOULD seems more appropriate. Changing the values is > typically very useful especially in the cases where the implementation > may be used in small devices and bigger routers as well. Agree. If it is possible for the implementation to clearly choose appropriate default values based on the capacity of the links and the devices where the implementation is going to be used, there is no point in exposing this to the user. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
