OK, I see now. I'm not at all sure what to suggest. That option did not occur to me while I was reading the draft, especially after I looked at RFC9000 (which given the definition is different doesn't really help).
If I'm the only one confused, then so be it. Thanks for the time, Deb On Thu, Jul 3, 2025 at 12:11 PM Thomas Fossati <[email protected]> wrote: > Hi Deb, > > On Thu, Jul 03, 2025 at 09:51:39AM +0100, Deb Cooley wrote: > >top posting, for clarity: > > > >Current: > >'the term "anti-amplification limit" means three times the amount of data > >received from an unvalidated address.' > > > >Suggest something like: > >'the term "anti-amplification limit" means an endpoint limits the amount > of > >data it sends to three times the amount of data received from an > >unvalidated address.' > > > >You are currently missing the whole concept of the end point not sending > >more than 3 times the data it receives. > > Yes, because the "anti-amplification limit" is just a quantity. > > When we use it in a sentence (in §6 and twice in §6.3), there is always > enough context to relate it to the specific send operation by a clearly > identifiable entity: > > "The receiver [...] limit the data sent to the unvalidated address to > the anti-amplification limit." > > "[...] the initiator can send a path_challenge message once per > round-trip time (RTT), up to the anti-amplification limit." > > "The initiator MAY use padding [...] up to the anti-amplification limit > [...]" > > What am I missing? > > cheers, t >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
