Dave Taht wrote:
>
> section 6 addition. (could use more verbiage)
>
> 6.3 "An AQM that is ECN aware MUST have overload protection.
I fear I cannot discern what you mean this to say. :^(
> It is trivial for a malbehaved application/worm/bot to mark all
> its packets with ECN and thus gain p
section 6 addition. (could use more verbiage)
6.3 "An AQM that is ECN aware MUST have overload protection.
It is trivial for a malbehaved application/worm/bot to mark all it's
packets with ECN and thus gain priority over other traffic not ecn marked.
6.4 Enabling ECN at the application layer re
Chairs, WG,
Thanks for all people who emailed me on and off list.
Apologies to be editing when we supposed to be in reading mode prior to
the IETF (!!). However, since this seems to me to be useful, I continue.
I have updated the "unpublished" current version - this is ready for
upload (includin
On Wed, 18 Mar 2015, Gorry Fairhurst wrote:
Removing "pitfalls" in the title, and replacing its use in the draft
with "operational difficulties", or words to that effect, seems
reasonable to me.
Thanks, this is something I think we can propose to the WG at the Dallas
meeting. Thoughts from oth
Thanks for getting back with comments.
On 18/03/2015 00:38, Greg Skinner wrote:
I noticed that the RFC 2119 boilerplate text (Key words for use in RFCs
to Indicate Requirement Levels such as "MUST") is missing. IMO, several
issues in Section 6 (and possibly Section 7) should have the
uncapitali
