Re: questions about draft-chadalapaka-command-ordering-00.txt

["Mallikarjun C." <cbm@rose.hp.com>]

Aaron,

Thanks for the review.

> 1) I think that the draft currently implies the section below from iSCSI
> is not always a MUST.  Is this the authors intent?

No.

The issue was: should initiators and targets *enforce* command ordering?
The answer was: Only the targets *enforce* it, but the initiators don't have to 
*use* it (initiators still have to satisfy other iSCSI-mandated requirements that
presumably were meant to help target do the enforcement).

I thought we picked the words carefully here, but I can now see that replacing
"command ordering" with "ordered command delivery" in 3.3.1(b) could improve
the readability of the text (since 3.2(a) summarizes the idea of the phrase
"ordered command delivery").

> 2)  I think the following text from section 6 implies that implementations
> should not comply with iSCSI, is this the authors intent as well? 

No, :-)  I do not see any text below the quoted text suggesting what 
you read into it.

Authors can substitute "However, here are certain things" with "However, 
here are certain additional things".  Hope that helps.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: <AClarke@attotech.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, February 25, 2003 12:52 PM
Subject: questions about draft-chadalapaka-command-ordering-00.txt 


> 
> I thank the authors for creating a document which
> "... provides guidance to system designers on how true command
> ordering solutions can be built based on iSCSI."
> 
> As a systems designer, I welcome such an effort.  I find the command
> ordering and recovery issues to be the most confusing aspect of the
> iSCSI standard.
> 
> I have a few questions about the draft...
> 
> 1) I think that the draft currently implies the section below from iSCSI
> is not always a MUST.  Is this the authors intent?
> 
> (From draft-ietf-ips-iscsi-20.txt)
> 3.2.2.1  Command Numbering and Acknowledging
> ...
>    On any connection, the iSCSI initiator MUST send the commands in
>    increasing order of CmdSN, except for commands that are
>    retransmitted due to digest error recovery and connection recovery.
> 
> (From draft-chadalapaka-command-ordering-00.txt)
> 3.3  Ordered command delivery
> 3.3.1  Issues
>      There has been a lot of  debate on this particular aspect in the IPS
>      WG.  Most of the debate was centered on two specific questions -
> ...
>            b)  Should [iSCSI] require initiators and targets to enforce
>               command ordering?
> ...
>      The final resolution of b) in section 3.3.1 by the iSCSI protocol
>      designers was in favor of not requiring the initiators to use com-
>      mand ordering always.  This resolution is reflected in dropping the
>      ACA requirement on the initiators, and allowing ABORT TASK TMF to
>      plug command holes etc.  The net result can be discerned by a care-
>      ful reader of [iSCSI] - the onus of command ordering is on the iSCSI
>      targets, while the initiators may or may not use command ordering.
> 
> 
> 2)  I think the following text from section 6 implies that implementations
> should not comply with iSCSI, is this the authors intent as well?  If so
> wouldn't this lead to interoperability problems?
> 
>     "In general, command ordering is automatically enforced if targets and
>      initiators comply with the iSCSI specification.  However, here are
>      certain things for the iSCSI initiators and targets to take note
> of...."
> 
> I would appreciate any comments--they would greatly help me with my work.
> 
> Thanks,
> 
> Aaron
> 
>