Remote Direct Memory Access (RDMA) Protocol Extensions
draft-ietf-storm-rdmap-ext-10

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

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-03-22 for -09)
No email
send info
- 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.)

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

(Pete Resnick) No Objection

Comment (2014-03-25 for -09)
No email
send info
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