Skip to main content

Remote Direct Memory Access Transport for Remote Procedure Call Version 1
draft-ietf-nfsv4-rfc5666bis-11

Yes

(Spencer Dawkins)

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)

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

Spencer Dawkins Former IESG member
Yes
Yes (for -10) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2017-02-28 for -10) Unknown
- 3.4.5: Can a requester DoS a responder by asking the
latter to read giga- or tera-bytes?  And the same question
the other way about for 3.4.6.

- 4.4.1: not having access to memory allocated for
"cancelled RPCs" also seems like a potential DoS that ought
be noted. Is it?

- General: I was surprised see no mention of DoS. Is that
covered in some reference? Even if so, I'd have expected
some discussion of DoS attacks and mitigations.

- 8.2.1: "Protection below the RDMA layer is a more
appropriate security mechanism for RDMA transports in
performance-sensitive deployments." I think that's a bit
over-stated. A deployment could be performance-sensitive
but yet prioritise application layer crypto for various
reasons. As you're really just talking about trade-offs,
and I think that's sufficiently explained already, I figure
you could omit that sentence.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -10) Unknown