Skip to main content

Remote Direct Memory Access (RDMA) over IP Problem Statement
draft-ietf-rddp-problem-statement-05

Yes

(Allison Mankin)
(Jon Peterson)
(Thomas Narten)

No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Margaret Cullen)
(Ned Freed)
(Steven Bellovin)
(Ted Hardie)

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

Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Thomas Narten Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
(was Discuss) No Objection
No Objection (2004-10-27) Unknown
Reviewed by John Loughney, Gen-ART
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Ned Freed Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2004-02-04) Unknown
  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/
Steven Bellovin Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown