I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The document describes "Known issues and best practices for the Use of Long Polling and                    Streaming in Bidirectional HTTP", and it has the following abstract:

   There is widespread interest in using the Hypertext Transfer Protocol
   (HTTP) to enable asynchronous or server-initiated communication from
   a server to a client as well as from a client to a server.  This
   document describes the known issues and the best practices related to
   the use of HTTP, as it exists today, to enable such "bidirectional
   HTTP".  The two existing mechanisms, called "HTTP long polling" and
   "HTTP streaming" are described.

The document is very clear and articulate and I have not found any security issues that were not covered appropriately in the Security Considerations sections.

I have two concerns regarding the use of "should", "must" etc.:

1. I have found at least one occurrence where a recommendation is made using lower cases "recommended" and "should". Should upper cases be used instead?

2. Similarly, parts of the text describes node behavior using lower cases "should" and "must". This makes it hard for the reader to differentiate between behavior specified in another standard document from behavior that can be reasonably expected from a deployed implementation. I would suggest that upper case requirements key words ("SHOULD", "MUST") be used if the behavior thereby enounced is specified within another RFC documents, and that document be cited next to the statement. 
 
Nits:

s/DOS attacks\.[RFC4732]/Denial-of-Service (DoS) attacks [RFC4732]/

Hope that helps,

--julien