iSCSI: DAP Last Call Comments

["Dave Peterson" <dap@cisco.com>]

T	p 36	2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in
this document, where is the means to request immediate delivery for a
command?
T	p 38	2.2.2.2 Response/Status Numbering and Acknowledging: 4th paragraph:
this paragraph is too vague which may result in different error recovery
initiations being implemented.
T	p 43	2.2.4 iSCSI Full Feature Phase: 16th paragraph: last sentence is not
correct since out of order data delivery is allowed (if negotiated)
T	p 73	4.2 Text Mode Negotiation: 6th paragraph: 3rd sentence: change the
"should" to a "must"
T	p 73	4.2 Text Mode Negotiation: 8th paragraph: the use of "Irrelevant" is
a potential interoperability problem. Need to further specify the use of
"Irrelevant".
T	p 73	4.2 Text Mode Negotiation: 9th paragraph: specify that a
"key=NotUnderstood" is applicable for "X-keys" only.
T	p 103	6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry
remain broken rendering it useless for tape operation. SCSI level error
detection and recovery is the preferred mechanism. Refer to previous emails
sent via the IPS reflector regarding this matter.
T	p 128	8.6 Considerations for State-dependent devices: last paragraph:
don't agree with the statement that error recovery at the iSCSI level
(specifically Retry in its current state) is advisable. Retry at the SCSI
level is feasible and is not difficult (i.e., READ POSITION and LOCATE
commands). This paragraph should be removed.
T	p 214	11.11 BidiInitialR2T: this text key provides no value and needs to
be removed. InitialR2T should be used for both uni and bidirectional
commands. In addition, if BidiInitialR2T were to be used, it will not
function via an iSCSI-FCP gateway.