iSCSI: Ch7 clarifications

["Wheat, Stephen R" <stephen.r.wheat@intel.com>]

Julian, I have a couple of section 7 questions.

The last paragraph of 7.1 states:

        It is optional for targets to support the replay functionality (as 
        agreed by the CommandReplaySupport text key at the login time) and 
        the allegiance switching (as agreed by the CommandFailoverSupport 
        text key at the login time), while they MUST support the retry bit 
        and the rest of the retry functionality described in this section.  
        When a target does not implement replay, it MUST reject the command 
        with a reason code of "Command Replay Not Supported". 

Question 1a:
If CommandReplaySupport must have been previously negotiated, isn't it a
protocol error for an initiator to request it if the target doesn't support
it, given that the target would never have negotiated to agree on replay?
And, as such, shouldn't the response be more drastic, following the path for
protocol errors?

Question 1b:
The ", while they MUST support ..." seems unnecessary, given that the
required actions for a target are otherwise specified.

I suggest striking the last sentence and a half and rework the paragraph to
state:
        Targets MAY support the replay functionality.  Actual use of replay
is 
        agreed by the CommandReplaySupport text key at login.

        Targets MAY support allegiance switching.  Actual use of allegiance
switching is
        agreed by the CommandFailoverSupport text key at login.


Question 2.  In Paragraph 7.4 The following is ambiguous:
         
             - If the discarded PDU is an iSCSI data PDU,  
                       a) Target MAY request retransmission with a R2T. 
                          [OR] 
                       b) Target MUST answer with a command response PDU 
                          with a response-code of delivery-subsystem-
                          failure and terminate the task.  If the target 
                          chooses to implement this, it MUST wait to 
                          receive all the data (signaled by a Data PDU 
                          with the final bit Set for all outstanding 
                          R2Ts) before sending the command response PDU. 

This could be interpreted two ways:
  1) the target could choose option (a) and *not* request retransmission
or
  2) if the target chooses to not request retransmission, it must execute
option (b).

If (2) is intended, then the MAY in (a) should be MUST.
If (1) is intended, then the MUST in (b) should be MAY.

A similar situation occurs a few paragraphs later, where initiator actions
are described.  The same situation appears in (a) and (b), but it is clearly
articulated in (e) (if neither (c) nor (d), then (e)).

Perhaps there is a convention that I'm unaware of where MAY-OR-MUST is
deterministic.  If so, I've learned something ;^)

But, MUST-OR-MUST seems more logical (to me).

Stephen