Re: iSCSI: DAP Last Call Comments

["Julian Satran" <Julian_Satran@il.ibm.com>]

Dave - Comments in text - Thanks, Julo

"Dave Peterson" <dap@cisco.com> Sent by: owner-ips@ece.cmu.edu 07/07/2002 11:19 PM Please respond to "Dave Peterson"

To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>         cc:                 Subject:        iSCSI: DAP Last Call Comments

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?

+++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++

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.

+++ the only bound required by protocol is stated here. The mechanisms described in 6 allow machines with different implementations to interoperate. The text is not vague. It just does say only what needs to be said. +++

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)

+++ the statement refers to unsolicited data for different commands on a given connection and is correct+++

T                 p 73                 4.2 Text Mode Negotiation: 6th paragraph: 3rd sentence: change the
"should" to a "must"

+++ so long as it is lower-case fine +++
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".

+++ Irrelevant is completely define and allows us to be build easier packages tolerant to different parameter combinations in a few exchanges. + We may do it implicitly but explicit is better++

T                 p 73                 4.2 Text Mode Negotiation: 9th paragraph: specify that a
"key=NotUnderstood" is applicable for "X-keys" only.

+++ It practically says this for the current version. We do not want to forbid it for other keys in future versions +++

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.
+++ Dave. The retry scheme for connection recovery implies that the other two levels are there.
So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described
will have to stay.
+++
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.
+++ that is not what we repeatedly hear. I will however make a "softer" statement. +++

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.

+++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it.
But I am still listening.
+++