Remote Direct Memory Access (RDMA) Protocol Extensions
draft-ietf-storm-rdmap-ext-10
Yes
(Martin Stiemerling)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Spencer Dawkins)
Note: This ballot was opened for revision 09 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
(for -09)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -09)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -09)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -09)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -09)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2014-03-25 for -09)
Unknown
Editorial nits: Please don't use [IB], [RSOCKETS], [OFAVERBS], etc., as nouns. Instead, on first use, say "Infiniband [IB]" and the like, and then use the word (not the reference) throughout the rest. Also, an expansion and/or reference for iWARP and RNIC would be helpful in the intro. 4.1 & 4.2: s/MUST be used/are used. What else would an implementation do? 4.1: Figure 2 also defines when the STag, Tagged Offset, and Queue Number fields MUST be provided for the RDMA Messages defined in this specification. I'm confused. Doesn't Figure 2 say that STag and TO are N/A for these messages? That's not a MUST. How about this instead: As shown in Figure 2, STag and Tagged Offset are not applicable for the RDMA Messages defined in this specification. Figure 2 also shows the appropriate Queue Number for each Opcode. 5: An RNIC that supports Atomic Operations as specified in this document MUST implement all Atomic Operation Codes defined in Figure 5. Do you really mean Figure 5? If so, say "both" instead of "all", or even better, try: An RNIC that supports Atomic Operations as specified in this document MUST implement both the FetchAdd operation as specified in section 5.1.1 and CmpSwap operation as specified in section 5.1.2. There are three requirements stated in the last paragraph of this section: MUST use Untagged Buffer model with QN=3, MUST use queue number 3, and MUST use MSN. Whenever I see MUST requirements, I always ask "Why MUST I do that?" If there's a good answer to that question, the explanation (like, "If you don't do this, the implementation will blow up because the other end will be expecting you to handle buffers bigger that you probably thought you needed") should probably be stated if it's not clear why. If the answer is, "Because if you're not doing that, you're not implementing the protocol", then the MUST is silly and should be replaced with "will" or "is". If the answer is, "No reason; we just think you should", then MUST isn't appropriate at all. So, for these three requirements, which answer is correct? (Probably useful to look at other requirements in the document and ask the same questions.) 5.2.1: AOpCode: The "MUST" is redundant. Already stated above. Remote Tagged Offset: It says "MAY start at an arbitrary offset". But I thought above it was stated that it MUST be 64-bit aligned. Did I misunderstand. Add or Swap Mask, Compare Data and Mask: s/MUST be set/is set
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -09)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-03-22 for -09)
Unknown
- Section 1 and elsewhere: There are a number of acronyms not expanded on 1st use. Doing so would be good, e.g iWARP. It'd also be nice to not use the reference as part of the sentence in at least some cases here, w.g. "...support in [IB]" assumes I can tell what is meant from the two letters IB. (This reader cannot:-) - I wondered if these operations (and RDMA generally) has been examined for potential timing side-channel attacks. If all RDMAP messages were sent via an encrypted channel, how much could I deduce from the timing of the messages and responses? (The pseudo code in section 5 suggested this question.)