Note: This ballot was opened for revision 05 and is now closed.

(Allison Mankin) Yes

(Thomas Narten) Yes

(Jon Peterson) Yes

(Harald Alvestrand) (was Discuss) No Objection

Reviewed by John Loughney, Gen-ART

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Ted Hardie) No Objection

(Russ Housley) No Objection

  The Introduction provides a clear description of the situation.  However,
  I find the Abstract very confusing.  I believe that some wordsmithing will
  greatly improve the Abstract.

  The use of IPsec, TLS, or any other protocol that provides authentication
  will not fit well into the proposed architecture.  The integrity check
  cannot be performed until the entire packet (or record in the case of TLS)
  is available in memory.  So, the data must be copied from the I/O interface
  to memory, which may involve some reassembly, before the integrity check
  can be performed.  This issue should be discussed in the second paragraph
  of the security considerations.

  The security considerations section talks about 'threats.'  The use does
  not align with the definitions in RFC 2828.  I suggest some rewording. I
  think the authors ought to look review the definition of 'vulnerability'
  in RFC 2828.

  s/IPSec/IPsec/

  s/privacy/confidentiality/

(Bert Wijnen) No Objection

(Alex Zinin) No Objection