Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h1PL5Vp26327
	for ips-outgoing; Tue, 25 Feb 2003 16:05:31 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from firegate.attotech.com (firegate.attotech.com [12.32.232.50])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h1PL5SW26317
	for <ips@ece.cmu.edu>; Tue, 25 Feb 2003 16:05:28 -0500 (EST)
Received: from [172.16.1.48] by firegate.attotech.com
	for ips@ece.cmu.edu
	id PAA08202; Tue Feb 25 15:52:52 2003
Subject: questions about draft-chadalapaka-command-ordering-00.txt 
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF18A24366.1917A65D-ON85256CD8.006D0DDD@attotech.com>
Date: Tue, 25 Feb 2003 15:52:20 -0500
X-MIMETrack: Serialize by Router on NOTESERV1/SERV/ATTO(Release 5.0.8 |June 18, 2001) at
 02/25/2003 03:52:21 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
To: ips@ece.cmu.edu
From: AClarke@attotech.com
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


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

